May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-124: ------------------------------------- I think we should probably use an annotation. That way we don't have to have too much along the lines of hand-wavy magic heuristics, especially if we add functions for other purposes in the future. > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-124: --------------------------------------- Do we want to use a {{@Producer}} annotation or just make assumptions if the parameter is a {{java.util.function.Function}}? > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-124) Ability to provide exception producer

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-124?page=com.atlassian.jira.plugi... ] James Perkins reassigned LOGTOOL-124: ------------------------------------- Assignee: James Perkins > Ability to provide exception producer > ------------------------------------- > > Key: LOGTOOL-124 > URL: https://issues.jboss.org/browse/LOGTOOL-124 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > Priority: Minor > Fix For: 2.1.0.Alpha3 > > > Sometimes you must use the same exception message for many different types of exception. It would be nice if you could give a parameter which can produce an exception, like this: > {code} > public interface MyLogs { > // ... > @Message(id = 1234, "The operation failed due to %s") > <T extends Throwable> T operationFailed(@Producer Function<String, T> fn, String thing); > } > {code} > And later at usage: > {code} > // ... > throw MyLogs.log.operationFailed(IOException::new, "thingy"); > {code} > A valid function parameter must return a type which is equal or assignable to the return type, and is assignable to Throwable. Other than that, it can be treated the same as as if you were dealing with a constructor class that has exactly one constructor, using the same matching/inference logic, meaning you could also accept BiFunction which accepts two arguments. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7949) Missing a simple way to enable Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7949?page=com.atlassian.jira.plugin.... ] Jan Kalina updated WFLY-7949: ----------------------------- Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/176, https://github.com/wildfly/wildfly/pull/10100 (was: https://github.com/wildfly-security-incubator/wildfly/pull/176) > Missing a simple way to enable Elytron > -------------------------------------- > > Key: WFLY-7949 > URL: https://issues.jboss.org/browse/WFLY-7949 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Critical > Labels: user_experience > Fix For: 11.0.0.Beta1 > > > There should be a simple way (e.g. a CLI script provided with AS distribution) which would enable the Elytron in subsystems. As the {{standalone-elytron.xml}} profile was removed now, users don't have a one-step way to use the Elytron. > I've put some CLI commands together for my testing, but I doubt this is a complete solution: > http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2712) Elytron - predefined-filter must have flag required in configurable-sasl-server-factory

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2712?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-2712: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2460 (was: https://github.com/wildfly/wildfly-core/pull/2459) > Elytron - predefined-filter must have flag required in configurable-sasl-server-factory > --------------------------------------------------------------------------------------- > > Key: WFCORE-2712 > URL: https://issues.jboss.org/browse/WFCORE-2712 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Ilia Vassilev > > Change the required flag to true for {{predefined-filter}} attribute in Elytron subsystem. > Elytron resource type {{configurable-sasl-server-factory}} has {{filters}} object-list attribute. Its attribute {{predefined-filter}} is an alternative for {{pattern-filter}} attribute. The {{pattern-filter}} has required flag set to true, but {{predefined-filter}} has it false. It results in possibility to add empty filter: > {code} > /subsystem=elytron/configurable-sasl-server-factory=t1:add(sasl-server-factory=elytron, filters=[{}]) > {"outcome" => "success"} > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1189) Create better way of masking passwords using modern PBE algorithm

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- pskopek commented on 12 Jan I don't think that we should start with simple obfuscation at current stage. We can consider it later. [1] For now I suggest to implement PB compatible version of MASK-xxx in KeyStoreCredentialStore. [2] We can also consider to introduce type to credential-reference which can point to credential store with InitialKey and all other parameters (IV, salt, iteration count) will be encoded in alias part of the reference. We don't have to change Elytron API as we already have PBE utility class in place. We can also later reimplement it with proper password types. Part [2] will also be usable in KeyStoreCredentialStore protection parameter, so users can decide which way they want to use it. > Create better way of masking passwords using modern PBE algorithm > ----------------------------------------------------------------- > > Key: ELY-1189 > URL: https://issues.jboss.org/browse/ELY-1189 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Peter Skopek > Assignee: Peter Skopek > > Create better way of masking passwords using modern PBE algorithm. > This bug contains discussion from PR: https://github.com/wildfly-security/wildfly-elytron/pull/619 > To have this documented and PR closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1189) Create better way of masking passwords using modern PBE algorithm

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- dmlloyd commented on 12 Jan Peter is right, the priority is to get the compatible implementation to be functional. Since the PB variant doesn't use IV, to me that means fixing MaskedPassword to only support the algorithms that fit its structure, and fixing its specific incompatiblities with PB. Then we can open JIRAs to look at encrypted two-way passwords and/or simple obfuscation algorithms later (rot13 is a simple example however it doesn't really account for the Unicode world we live in today; a JIRA is an OK place to discuss this). > Create better way of masking passwords using modern PBE algorithm > ----------------------------------------------------------------- > > Key: ELY-1189 > URL: https://issues.jboss.org/browse/ELY-1189 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Peter Skopek > Assignee: Peter Skopek > > Create better way of masking passwords using modern PBE algorithm. > This bug contains discussion from PR: https://github.com/wildfly-security/wildfly-elytron/pull/619 > To have this documented and PR closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1189) Create better way of masking passwords using modern PBE algorithm

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- zregvart commented on 12 Jan All good points, let me open up another can of worms Assuming that the goal of MaskedPassword is to prevent someone from glancing over and seeing the password in clear text I would argue that the current MaskedPassword could be split into two implementations PickBoxMaskedPassword and SimpleMaskedPassword (example name). PickBoxMaskedPassword would remain for compatibility with PicketBox. While SimpleMaskedPassword would use simple algorithm to obfuscate the password (ROT13, XOR). I think there is really little value from cryptography standpoint, form using an KDF for generating the key to transform (encrypt/decrypt) clear text password and exposing all the parameters for the KDF (in this case the initial secret, hardcoded "somearbitr...") and the transformation (salt, iteration count, IV) also in the clear. I also think that it could be CredentialStore-s domain to pick if it wants to derive key for its protection from a Password (probably transformed to ClearPasswordSpec) by using a KDF of choice and so there should be no need for using a KDF in MaskedPassword. Also using the KDF (SecretKeyFactory) in the current implementation with no with 0 iterations and no salt (default for PBEKeySpec if not specified) is not adding any security as the key would be used verbatim (check the getEncoded of the resulting SecretKey). > Create better way of masking passwords using modern PBE algorithm > ----------------------------------------------------------------- > > Key: ELY-1189 > URL: https://issues.jboss.org/browse/ELY-1189 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Peter Skopek > Assignee: Peter Skopek > > Create better way of masking passwords using modern PBE algorithm. > This bug contains discussion from PR: https://github.com/wildfly-security/wildfly-elytron/pull/619 > To have this documented and PR closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1189) Create better way of masking passwords using modern PBE algorithm

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- zregvart commented on 11 Jan Good discussion guys, let me just jump in with a little tidbit, even though RFC2898 defines PBKDF1, there is clear wording on not actually using it (Section 5[1]). My point being that PBE algorithms that do not need persistence of IV would only be deprecated ones (SHA1/RC4 and MD5/DES) that are still using PBKDF1 mode. So it might make sense to include IV in the MaskedPassword by default. [1] https://tools.ietf.org/html/rfc2898#section-5 > Create better way of masking passwords using modern PBE algorithm > ----------------------------------------------------------------- > > Key: ELY-1189 > URL: https://issues.jboss.org/browse/ELY-1189 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Peter Skopek > Assignee: Peter Skopek > > Create better way of masking passwords using modern PBE algorithm. > This bug contains discussion from PR: https://github.com/wildfly-security/wildfly-elytron/pull/619 > To have this documented and PR closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1189) Create better way of masking passwords using modern PBE algorithm

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1189?page=com.atlassian.jira.plugin.s... ] Peter Skopek commented on ELY-1189: ----------------------------------- dmlloyd commented on 11 Jan This is a fair point @zregvart. But from an API perspective it can cause a problem since the IV necessarily has to impact the equality of a Password object, being a constituent part of its fields. Since security is not really an expectation with masked passwords (it's a two-way password type with no ancillary information, meaning that if you have the mask string, you have the original password), it might make sense to have a separate MaskedPassword versus EncryptedPassword, the latter including an IV? Or maybe it's simply not worth worrying about the IV variants (since that's essentially a new feature). > Create better way of masking passwords using modern PBE algorithm > ----------------------------------------------------------------- > > Key: ELY-1189 > URL: https://issues.jboss.org/browse/ELY-1189 > Project: WildFly Elytron > Issue Type: Task > Components: Credential Store > Reporter: Peter Skopek > Assignee: Peter Skopek > > Create better way of masking passwords using modern PBE algorithm. > This bug contains discussion from PR: https://github.com/wildfly-security/wildfly-elytron/pull/619 > To have this documented and PR closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 May 2017