July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1304) Elytron subsystem does not expose digest-sha-384 for digest password

by Martin Choma (JIRA)

Martin Choma created ELY-1304: --------------------------------- Summary: Elytron subsystem does not expose digest-sha-384 for digest password Key: ELY-1304 URL: https://issues.jboss.org/browse/ELY-1304 Project: WildFly Elytron Issue Type: Bug Reporter: Martin Choma Assignee: Darran Lofthouse For the sake of completeness add digest-sha-384 to allowed values of algorithm attribute of set-password operation {code:title=/subsystem=elytron/ldap-realm=a:read-operation-description(name=set-password)} "digest" => { "type" => OBJECT, "description" => "A digest password.", "expressions-allowed" => false, "required" => false, "nillable" => true, "value-type" => { "algorithm" => { "type" => STRING, "description" => "The algorithm used to encrypt the password.", "expressions-allowed" => false, "required" => false, "nillable" => true, "default" => "digest-sha-512", "allowed" => [ "digest-md5", "digest-sha", "digest-sha-256", "digest-sha-512" ] }, "password" => { "type" => STRING, "description" => "The actual password to set.", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L }, "realm" => { "type" => STRING, "description" => "The realm.", "expressions-allowed" => false, "required" => true, "nillable" => false, "min-length" => 1L, "max-length" => 2147483647L } } }, {code} Passwords of types otp, salted-simple-digest, simple-digest already expose sha-384 variant. Seems to me underlying Elytron implementation is already prepared for that. {code:java|title=DigestPasswordImpl.java} private static MessageDigest getMessageDigest(final String algorithm) throws NoSuchAlgorithmException { switch (algorithm) { case ALGORITHM_DIGEST_MD5: return MessageDigest.getInstance("MD5"); case ALGORITHM_DIGEST_SHA: return MessageDigest.getInstance("SHA-1"); case ALGORITHM_DIGEST_SHA_256: return MessageDigest.getInstance("SHA-256"); case ALGORITHM_DIGEST_SHA_384: return MessageDigest.getInstance("SHA-384"); case ALGORITHM_DIGEST_SHA_512: return MessageDigest.getInstance("SHA-512"); default: throw log.noSuchAlgorithmInvalidAlgorithm(algorithm); } } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2205) DISCARD ignores the DONT_LOOPBACK transient flag

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2205?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2205: -------------------------------- Actually, both setting the local address and copying the message is done in the transport, so I'm going to remove {{loopback()}} altogether and simply call {{down_prot.down(msg)}}. > DISCARD ignores the DONT_LOOPBACK transient flag > ------------------------------------------------ > > Key: JGRP-2205 > URL: https://issues.jboss.org/browse/JGRP-2205 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.4 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 4.0.5 > > > When {{discard_all = true}}, {{DISCARD}} does its own loopback, and doesn't check for {{DONT_LOOPBACK}} like {{TP}}. It always sends the message back up, even if {{excludeItself = false}}. > If possible, {{DISCARD}} should just set the message destination to the local address and pass the message down. That way, {{TP}} would decide make the loopback decision, and using the {{TP}} thread pool would also make the thread name nicer in the logs. (Currently the thread name is {{Thread-n}}, which means searching for the test name in our test suite's log misses some messages.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2205) DISCARD ignores the DONT_LOOPBACK transient flag

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2205?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2205: -------------------------------- I'll do that except that we cannot set {{dest = local_addr}} as it might be a multicast message ({{dest == null}}) > DISCARD ignores the DONT_LOOPBACK transient flag > ------------------------------------------------ > > Key: JGRP-2205 > URL: https://issues.jboss.org/browse/JGRP-2205 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.4 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 4.0.5 > > > When {{discard_all = true}}, {{DISCARD}} does its own loopback, and doesn't check for {{DONT_LOOPBACK}} like {{TP}}. It always sends the message back up, even if {{excludeItself = false}}. > If possible, {{DISCARD}} should just set the message destination to the local address and pass the message down. That way, {{TP}} would decide make the loopback decision, and using the {{TP}} thread pool would also make the thread name nicer in the logs. (Currently the thread name is {{Thread-n}}, which means searching for the test name in our test suite's log misses some messages.) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1303) WildFly Elytron Tool, Vault command should support set security provider to convert vaults to custom credential store implementation.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1303?page=com.atlassian.jira.plugin.s... ] Hynek Švábek moved WFLY-9103 to ELY-1303: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-1303 (was: WFLY-9103) Component/s: Credential Store (was: Security) > WildFly Elytron Tool, Vault command should support set security provider to convert vaults to custom credential store implementation. > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: ELY-1303 > URL: https://issues.jboss.org/browse/ELY-1303 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > > WildFly Elytron Tool, Vault command should support set security provider to convert vaults to custom credential store implementation. > Something similar to credential-store command. > http://undertheelytron.blogspot.cz/2017/07/custom-test-credential-store.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1666) Change the return result on DTs with policy C, C+ and C#

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1666?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1666: ---------------------------------- Description: The spec says that decision tables with no matching rules should always return null, but that does not make much sense for DTs with hit policies C, C+ and C#. The return results for these cases should be: C = [ ] (empty list) C# = 0 Also, open a ticket to the DMN RTF to fix it in the spec. was: The spec says that decision tables with no matching rules should always return null, but that does not make much sense for DTs with hit policies C, C+ and C#. The return results for these cases should be: C = [ ] (empty list) C+ = 0 C# = 0 Also, open a ticket to the DMN RTF to fix it in the spec. > Change the return result on DTs with policy C, C+ and C# > -------------------------------------------------------- > > Key: DROOLS-1666 > URL: https://issues.jboss.org/browse/DROOLS-1666 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.1.0.Final > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.2.0.Final > > > The spec says that decision tables with no matching rules should always return null, but that does not make much sense for DTs with hit policies C, C+ and C#. > The return results for these cases should be: > C = [ ] (empty list) > C# = 0 > Also, open a ticket to the DMN RTF to fix it in the spec. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1666) Change the return result on DTs with policy C and C#

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1666?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1666: ---------------------------------- Summary: Change the return result on DTs with policy C and C# (was: Change the return result on DTs with policy C, C+ and C#) > Change the return result on DTs with policy C and C# > ---------------------------------------------------- > > Key: DROOLS-1666 > URL: https://issues.jboss.org/browse/DROOLS-1666 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.1.0.Final > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 7.2.0.Final > > > The spec says that decision tables with no matching rules should always return null, but that does not make much sense for DTs with hit policies C, C+ and C#. > The return results for these cases should be: > C = [ ] (empty list) > C# = 0 > Also, open a ticket to the DMN RTF to fix it in the spec. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-154) Log rotations should be more resilient to failed rotations

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-154?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-154: ------------------------------------ Assignee: James Perkins > Log rotations should be more resilient to failed rotations > ---------------------------------------------------------- > > Key: LOGMGR-154 > URL: https://issues.jboss.org/browse/LOGMGR-154 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 2.0.8.Final, 2.1.0.Alpha3 > > > If a failure occurs while rotating a file the file handler will stop working. The file handler should instead report the failed rotation, but keep allowing messages to be written. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9124) Upgrade WildFly Transaction Client to 1.0.0.CR3

by David Lloyd (JIRA)

David Lloyd created WFLY-9124: --------------------------------- Summary: Upgrade WildFly Transaction Client to 1.0.0.CR3 Key: WFLY-9124 URL: https://issues.jboss.org/browse/WFLY-9124 Project: WildFly Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9123) Upgrade JBoss EJB Client to 4.0.0.CR6

by David Lloyd (JIRA)

David Lloyd created WFLY-9123: --------------------------------- Summary: Upgrade JBoss EJB Client to 4.0.0.CR6 Key: WFLY-9123 URL: https://issues.jboss.org/browse/WFLY-9123 Project: WildFly Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3097) Subsystem xml writers should be lazy created when needed

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-3097: ----------------------------------- Summary: Subsystem xml writers should be lazy created when needed Key: WFCORE-3097 URL: https://issues.jboss.org/browse/WFCORE-3097 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Tomaz Cerar Assignee: Tomaz Cerar Currently subsystemWriter is registered up-front with instance of writer. But in most scenarios that uses use server in production, writers are never even used as they only marshal configuration when it is changed via mgmt api, otherwise there is no need for them to be even initiated. We should be able to do similar as we did with parsers when they are only created when needed and after their usage they are GC-able. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 July 2017