[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
It doesn't have to be a dichotomy. We just have to adhere to the contract of the password class, which is that a Password object contains everything needed to represent the password, and that all of a Password object's fields are inputs into the password content (i.e. no "optional" data is allowed).
Since IV is not required for all masking types, then we need to either restrict the MaskedPassword type to only PBEwithMD5andDES (and other algorithms that may exist with no requirement to use IV) or else introduce a second MaskedPasswordWithIV type which includes IV, with a corresponding AlgorithmParameterSpec if necessary.
In order to store such a password, you could (for example) introduce a credential store which stores the IV and/or initial key material in the configuration for the store, or uses a constant (like PB), and stores only the ciphertext in the store itself, assembling the Password object only on read. But doing so is not necessary. Our normal keystore-backed credential store can (and should) easily encode the additional information alongside the password (this credential store implementation simply DER-encodes the constituent parts of each password type).
> 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
[JBoss JIRA] (DROOLS-1313) Memory Leak - but is this a supported scenario for Dynamic rule management
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1313?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1313.
---------------------------------
Resolution: Won't Fix
> Memory Leak - but is this a supported scenario for Dynamic rule management
> --------------------------------------------------------------------------
>
> Key: DROOLS-1313
> URL: https://issues.jboss.org/browse/DROOLS-1313
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: SAVE_SimpleTest.java, SAVE_SimpleTest2.java, SAVE_SimpleTest4.java, SAVE_SimpleTest5.java, SimpleTest2_dump1.PNG, SimpleTest2_dump2.PNG, SimpleTest2_dump3.PNG, SimpleTestDump1.PNG, SimpleTestDump2.PNG, SimpleTestDump3.PNG, heap.png, simpleTestThirdDump4.png
>
>
> I have a reproducer that shows a clear memory leak based on heap dumps created and reviewing them with the Eclipse Memory Analyzer tool (http://www.eclipse.org/mat/).
> However, I am not sure this is a supported scenario. If this is a supported approach this needs to get fixed, otherwise we need to use another approach.
> The attached source does this:
> +*Initialize stuff*+
> - Create a new ReleaseId
> - Create a new KieFileSystem
> - Generate and write the PomXML for the ReleaseId created above
> - Create a new KieModuleModel
> - Create a new KieBaseModel
> - Write the ModuleModel XML to the KieFileSystem
> - Write 2 rules into the KieFileSystem
> +*1st build and dump*+
> - Create a new KieBuilder
> - Do a buildall() with the KieBuilder
> - Create a new KieContainer
> - Create a new KieSession from the KieContainer
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestFirstDump.dmp), see SimpleTestDump1.png as you can see we have 2 classloaders for each class created for these rules. This is not the leak, yet, just curious if this is expected.
> +*2nd build and dump*+
> - Delete 2 rules from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestSecondDump.dmp), see SimpleTestDump2.png.
> - Rule_120_Triggered_Part_1_ 0 is not there
> - Another class loader and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> +*3rd build and dump*+
> - Delete 1 rule from the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Add 2 new rules to the KieFileSystem created above
> - Call incrementalBuild() on the KieBuilder created above
> - Call updateToVersion() on the KieContaincer created above, using the SAME ReleaseID created above
> - Print out the rules in the KieContainer for the package used in my rules
> - Create a java heap dump (SimpleTestThirdDump.dmp), see SimpleTestDump3.png.
> - Rule_120_Triggered_Part_1_ 0 is STILL not there
> - TWO more class loaders and instances of Rule_Internal_rule_0_DefaultConsequenceInvoker is present ( I think this is the leak)
> - Another class loader and instances of Rule_120_Triggered_part_10DefaultConsequenceInvoker is present ( I think this is also part of the leak)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[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 11 Jan
We need this new type of credential store to properly define decrypt "facility" of masked passwords.
https://issues.jboss.org/browse/ELY-868
Example of usage:
{code:xml}
<credential-stores>
<credential-store name="test" relative-to="jboss.server.data.dir">
<uri>cr-store://test?create.storage=true</uri>
<credential-reference store="masked-cs" alias="MASK-OCwoJ1d1RyGXVkUEuVCouA=="/>
</credential-store>
<credential-store name="masked-cs" type="PasswordBasedEncryptionCredentialStore">
<uri>cr-store://masked-cs?salt=SALTsalt;iteration=234;keyAlgoritm=PBEWithHmacSHA1andAES_128;encodedIV=WzVT5uUpEoXAPihMYzAIhQ==</uri>
<credential-reference clear-text="ThisIsStrangeInitialKey"/>
</credential-store>
</credential-stores>
{code}
dmlloyd commented on 11 Jan
I disagree with this change; using a whole credential store for one password format seems wrong. Instead we should be using "MaskedPassword" in a regular credential store, or even in places where regular passwords are allowed as a special expression (I believe previously we used "MASK-" for this purpose).
pskopek commented on 11 Jan
This change will allow several credential-references to use one set of parameters to PBE algorithm.
credential-reference can be used elsewhere in other subsystems.
I thought we are not going to use special expressions to supply passwords and we leave what we have to PicketBox vault/MASK usage.
pskopek commented on 11 Jan
oops, I see the problem. Putting this on hold to fix it.
dmlloyd commented on 11 Jan
Vault expressions should go, yes. But I think there are good arguments for allowing masked passwords to be used in places where clear passwords would otherwise be allowed.
pskopek commented on 11 Jan
I agree that masked passwords should be used at places where clear passwords are allowed.
Only problem is that we have to separate IV and InitialKey definitions/locations from salt and iteration.
My idea is to use new type of credential store for IV and InitialKey and credential-reference or special expression will hold salt, iteration and actual encrypted data.
Do you agree @dmlloyd ?
dmlloyd commented on 11 Jan
If the masked form of the password depends on IV then I guess the IV should be part of the MaskedPassword itself... then things which represent a masked password in text form would have to have configuration to tell what IV to use. Where do we store the IV today under PB?
dmlloyd commented on 11 Jan
The work of @zregvart is also tied into this.
pskopek commented on 11 Jan
As far as I remember PB is using different algorithm "PBEwithMD5andDES" which doesn't require IV.
Sure IV could be part of MaskedPassword, but still we have the InitialKey.
It could be constant like in PB but having chance to store it inside credential store will be much better.
> 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
[JBoss JIRA] (DROOLS-947) Replace org.kie.api.runtime.ObjectFilter with an interface for org.kie.api.runtime.ClassObjectFilter
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-947?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-947.
--------------------------------
Resolution: Out of Date
> Replace org.kie.api.runtime.ObjectFilter with an interface for org.kie.api.runtime.ClassObjectFilter
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-947
> URL: https://issues.jboss.org/browse/DROOLS-947
> Project: Drools
> Issue Type: Task
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Marco Rietveld
> Assignee: Mario Fusco
> Priority: Minor
>
> Because the ObjectFilter interface does not have any get/setters, it's impossible to implement serialization for implemenation of this class.
> We should either make ObjectFilter implement get/setFilteredClass or otherwise add subinterfaces (ClassObjectFilter, ClassNameObjectFilter) fo this interface, IMHO.
> There is an ObjectFilter field in the GetObjectsCommand, which will be available for use in the remote API's, because of it's use by the BatchExecutionCommandImpl class.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-833) PermGen issue with Kie CI
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-833?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-833.
--------------------------------
Resolution: Out of Date
> PermGen issue with Kie CI
> -------------------------
>
> Key: DROOLS-833
> URL: https://issues.jboss.org/browse/DROOLS-833
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: RHEL 6.5, JDK 1.7.0_71, Wildfly 8.2, Sonatype Nexus 2.11.3-0
> Reporter: C R
> Assignee: Mario Fusco
>
> We're facing a lot of issues with permgen OOM errors while using the KIE CI implementation to get the rules during runtime from a Nexus host.
> A jmap analysis shows that 414MB of dead permgen is produced by org/eclipse/sisu/space/CloningClassSpace$CloningClassLoader@0x00000007ef60b6a0
> With a dependency tree analysis it's shown, that only kie CI uses the sisu classes:
> +- org.kie:kie-ci:jar:6.2.0.Final:compile
> [INFO] | +- org.apache.maven:maven-artifact:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-core:jar:3.2.2:compile
> [INFO] | | +- org.apache.maven:maven-repository-metadata:jar:3.2.2:compile
> [INFO] | | +- org.codehaus.plexus:plexus-interpolation:jar:1.19:compile
> [INFO] | | +- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:compile
> [INFO] | | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile
> [INFO] | +- org.apache.maven:maven-model:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-model-builder:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-plugin-api:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-settings:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-settings-builder:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-compat:jar:3.2.2:compile
> [INFO] | +- org.apache.maven:maven-aether-provider:jar:3.2.2:compile
> [INFO] | +- org.apache.maven.wagon:wagon-provider-api:jar:1.0:compile
> [INFO] | +- org.codehaus.plexus:plexus-classworlds:jar:2.5.1:compile
> [INFO] | +- org.codehaus.plexus:plexus-utils:jar:3.0.17:compile
> [INFO] | +- org.eclipse.aether:aether-api:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-util:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-connector-basic:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-spi:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-transport-wagon:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-transport-file:jar:1.0.0.v20140518:compile
> [INFO] | +- org.eclipse.aether:aether-transport-http:jar:1.0.0.v20140518:compile
> [INFO] | | \- org.slf4j:jcl-over-slf4j:jar:1.6.2:compile
> [INFO] | +- org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5:compile
> [INFO] | | \- org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.0.0.M5:compile
> [INFO] | +- org.apache.ant:ant:jar:1.8.2:compile
> [INFO] | | \- org.apache.ant:ant-launcher:jar:1.8.2:compile
> [INFO] | +- org.apache.maven.wagon:wagon-http:jar:2.0:compile
> [INFO] | | \- org.apache.maven.wagon:wagon-http-shared4:jar:2.0:compile
> [INFO] | | \- org.jsoup:jsoup:jar:1.6.1:compile
> [INFO] | +- org.sonatype.plexus:plexus-cipher:jar:1.4:compile
> [INFO] | \- org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:compile
> [INFO] | \- aopalliance:aopalliance:jar:1.0:compile
> The most current version of the sisu implementation is 0.3.1 while kie-ci is using 0.0.0.M5. Maybe this is related to a bug in sisu with this old version.
> Is it possible to include a newer version of sisu with ki-ci?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1373) Rules are not removed from the KieModule/KieContainer
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1373?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1373.
---------------------------------
Resolution: Out of Date
> Rules are not removed from the KieModule/KieContainer
> -----------------------------------------------------
>
> Key: DROOLS-1373
> URL: https://issues.jboss.org/browse/DROOLS-1373
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: NotRemovingRules.java, drools-1373.PNG
>
>
> I have attached a reproducer named NotRemovingRules.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 2 rules and removes 2 rules and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the last .dmp file created names ckpoint3.drl you will see that rules named like
> org.drools.compiler.integraionTests.Rule_120#0DefaultConsequenceInvoker are still present. However, if you examine the console or System.out you will notice the code is executing that is removing the rules from the KieModule/KieContainer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (DROOLS-1386) NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1386?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1386.
---------------------------------
Resolution: Cannot Reproduce Bug
> NPE in org.drools.core.common.TupleSetsImpl.setNextTuple
> --------------------------------------------------------
>
> Key: DROOLS-1386
> URL: https://issues.jboss.org/browse/DROOLS-1386
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.5.0.Final, 7.0.0.Beta4
> Reporter: Arkady Syamtomov
> Assignee: Mario Fusco
> Priority: Critical
>
> In our integration tests which were perfectly running with drools 6.3.0.Final, now we have failures with the following exception during the rules evaluation:
> java.lang.NullPointerException: null
> at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.reteoo.QueryElementNode$UnificationNodeViewChangedEventListener.rowRemoved(QueryElementNode.java:444) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftDeletes(PhreakQueryTerminalNode.java:154) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:46) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evalStackEntry(RuleNetworkEvaluator.java:198) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:141) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:970) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1312) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1251) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1364) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1355) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1346) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final-redhat-2.jar:6.5.0.Final-redhat-2]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months