[JBoss JIRA] (WFLY-10031) Scripts throws "illegal reflective access" warning on JDK9
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10031?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-10031:
-----------------------------------------
[~jamezp] I think you may already have an issue open for this.
> Scripts throws "illegal reflective access" warning on JDK9
> ----------------------------------------------------------
>
> Key: WFLY-10031
> URL: https://issues.jboss.org/browse/WFLY-10031
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Security
> Reporter: Marek Kopecký
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> *Description of the issue:*
> Scripts throws "illegal reflective access" warning on JDK9.
> *How reproducible:*
> Always with JDK9
> *Steps to Reproduce:*
> * ./jboss-cli.sh "echo test"
> * ./add-user.sh -u test4 -p Test123* -s
> * ./appclient.sh -v
> * ./wsconsume.sh
> * ./wsprovide.sh
> * ./domain.sh
> * ./standalone.sh
> *Actual results:*
> {noformat}
> [hudson@rhel7-large-9887 bin]$ java --version
> java 9.0.4
> Java(TM) SE Runtime Environment (build 9.0.4+11)
> Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./jboss-cli.sh "echo test"
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> test
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./add-user.sh -u test4 -p Test123* -s
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> [hudson@rhel7-large-9887 bin]$ cat ../standalone/configuration/mgmt-users.properties | tail -n 1
> test4=a95aa9d159b7afe0cc9d3795061551ad
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> {noformat}
> [hudson@rhel7-large-9887 bin]$ ./appclient.sh -v
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jboss.logmanager.LogManager$2 (jar:file:/home/hudson/hudson_workspace/workspace/early-testing-scripts-unix/9774dccf/wildfly/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.0.9.Final.jar!/) to constructor java.util.logging.Level$KnownLevel(java.util.logging.Level)
> WARNING: Please consider reporting this to the maintainers of org.jboss.logmanager.LogManager$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> 06:11:52,205 INFO [org.jboss.modules] (main) JBoss Modules version 1.7.0.Final
> WildFly Full 13.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Final)
> [hudson@rhel7-large-9887 bin]$
> {noformat}
> *Expected results:*
> No warnings
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-9969) JDK9 + FIPS BC, unable to configure
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9969?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-9969:
------------------------------------
Finally I have managed to initialize BC provider in WildFly
* Define org.bouncycastle.fips module:
{code}
/jboss-eap-7.2/modules/system/layers/base/org/bouncycastle/fips/main
[mchoma@localhost main]$ tree
.
├── bc-fips-1.0.0.jar
├── service-loader-resources
│ └── META-INF
│ └── services
│ └── java.security.Provider
└── module.xml
{code}
* Where module.xml is
{code}
<module name="org.bouncycastle.fips" xmlns="urn:jboss:module:1.6">
<properties>
<property name="jboss.api" value="private"/>
</properties>
<resources>
<resource-root path="service-loader-resources"/>
<resource-root path="bc-fips-1.0.0.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="sun.jdk"/>
</dependencies>
</module>^M
{code}
* And java.security.Provider file's content is
{code}
org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
{code}
* Add org.bouncycastle.fips as dependency for org.jboss.as.server
{code}
<module name="org.bouncycastle.fips" services="import"/>
{code}
> JDK9 + FIPS BC, unable to configure
> -----------------------------------
>
> Key: WFLY-9969
> URL: https://issues.jboss.org/browse/WFLY-9969
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Final
> Reporter: Martin Choma
>
> * Configure BouncyCastleFipsProvider in java
> {code:title=$\{jdk9_home\}/conf/security/java.security}
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> security.provider.2=SUN
> security.provider.3=SunRsaSign
> security.provider.4=SunEC
> security.provider.5=SunJSSE BCFIPS
> security.provider.6=SunJCE
> security.provider.7=SunJGSS
> security.provider.8=SunSASL
> security.provider.9=XMLDSig
> security.provider.10=SunPCSC
> security.provider.11=JdkLDAP
> security.provider.12=JdkSASL
> security.provider.13=SunPKCS11
> {code}
> * configure -cp of java process based on https://docs.oracle.com/javase/9/security/howtoimplaprovider.htm#JSSEC-GU.... It means in $\{jboss_home\}/bin/standalone.conf put -cp option with bcfips jar
> {{JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar"}}
> * Configure additional logging
> {code}
> /subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=ALL)
> /subsystem=logging/logger=org.wildfly.extension.elytron:add(level=ALL)
> {code}
> * Run CLI command usink BCFKS key store type
> {{/subsystem=elytron/key-store=bcfks_keystore:add(path=keystore.bcfks,relative-to=jboss.server.config.dir, type="BCFKS", credential-reference=\{clear-text=password\})}}
> * For some reason BouncyCastleFipsProvider is not listed among providers returned by Security.getProviders() and therefore BCFKS can't be resolved
> {code}
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /home/mchoma/eap/7.2.0.EL12.CR1/jboss-eap-7.2
> JAVA: /opt/java/jdk-9.0.1_bcfips/bin/java
> JAVA_OPTS: -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -cp /home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n
> =========================================================================
> ...
> 09:20:16,630 TRACE [org.wildfly.extension.elytron] (MSC service thread 1-3) No provider identified for name [null] and algorithm [BCFKS] between [SUN version 9, ApacheXMLDSig version 2.11, SunRsaSign version 9, SunEC version 9, SunJSSE version 9, SunJCE version 9, SunJGSS version 9, SunSASL version 9, XMLDSig version 9, SunPCSC version 9, JdkLDAP version 9, JdkSASL version 9, SunPKCS11 version 9, SunDeploy-MozillaJSS version 1.5, WildFlyElytron version 1.0, TLSP version 1.0, openssl version 1.0]
> 09:20:16,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.key-store.bcfks_keystore: org.jboss.msc.service.StartException in service org.wildfly.security.key-store.bcfks_keystore: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:148)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693)
> at org.jboss.msc@1.3.2.Final-redhat-1//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads@2.3.1.Final-redhat-1//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.base/java.lang.Thread.run(Thread.java:844)
> Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00012: No suitable provider found for type 'BCFKS'
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.resolveProvider(KeyStoreService.java:156)
> at org.wildfly.extension.elytron@4.0.0.CR1-redhat-1-20180228//org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:110)
> ... 8 more
> {code}
> * With same java I can run succesfully this java code
> {code:java|title=TestBCLoaded.java}
> import java.security.*;
> public class TestBCLoaded {
> public static void main(String[] args) {
> Provider p = Security.getProvider("org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
> if (p==null){
> System.out.println("Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider");
> }
> p = Security.getProvider("BouncyCastleFipsProvider");
> if (p==null){
> System.out.println("Not Loaded: BouncyCastleFipsProvider");
> }
> p = Security.getProvider("BCFIPS");
> if (p==null){
> System.out.println("Not Loaded: BCFIPS");
> } else {
> System.out.println("Provider name is " + p.getName());
> System.out.println("Provider version # is " + p.getVersion());
> System.out.println("Provider info is " + p.getInfo());
> }
> }
> }
> {code}
> {code}
> [mchoma@localhost jdk9Test]$ java -cp .:/home/mchoma/.m2/repository/org/bouncycastle/fips/bc-fips/1.0.0/bc-fips-1.0.0.jar TestBCLoaded
> Not Loaded: org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> Not Loaded: BouncyCastleFipsProvider
> Provider name is BCFIPS
> Provider version # is 0.9
> Provider info is BouncyCastle Security Provider (FIPS edition) v0.90
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (DROOLS-2391) Cannot compare int's division result to double
by Viacheslav Krot (JIRA)
Viacheslav Krot created DROOLS-2391:
---------------------------------------
Summary: Cannot compare int's division result to double
Key: DROOLS-2391
URL: https://issues.jboss.org/browse/DROOLS-2391
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.4.1.Final
Reporter: Viacheslav Krot
Assignee: Mario Fusco
I guess this is a bug - division of int fields in when part cannot be compared to double.
For example with class A having two int fields following rule does not work
when
$a: A(a == 1, b == 2, a / b < 0.99)
but this works:
when
$a: A(a == 1, b == 2, a / b < 1.0)
Result of same expresson printed to output - System.out.println($a.a / $a.b) gives correct result of type Double.
Why does it not work in when part?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (WFLY-10034) wsconsume and wsprovide scripts should be synced
by Jan Blizňák (JIRA)
Jan Blizňák created WFLY-10034:
----------------------------------
Summary: wsconsume and wsprovide scripts should be synced
Key: WFLY-10034
URL: https://issues.jboss.org/browse/WFLY-10034
Project: WildFly
Issue Type: Bug
Components: Scripts, Web Services
Affects Versions: 12.0.0.Final
Reporter: Jan Blizňák
Assignee: Jan Blizňák
After several jiras changing the wsconsume and wsprovide shell and batch scripts there shoud be some clean up and synchronization of their contents.
Eg. WFLY-9850 was fixed only for wsprovide.sh but the same issue is in wsconsume.sh
Eg2. tools.jar is added to classpath in wsconsume scripts while it isn't in wsprovide counterpart - we should remove it as it is not needed anymore.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1541) local-kerberos CredentialSource does not work with IBM java
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1541?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1541 at 3/15/18 11:46 AM:
-----------------------------------------------------------
It looks *useDefaultCcache* is not sufficient on Fedora with IBM JDK defaults.
It works if I set path to the ccache manually by klist output:
{code:java}
options.put("useCcache", "FILE:/tmp/krb5cc_1000");
{code}
-> Path to the ccache should part of the local-kerberos credential def in xml.
was (Author: honza889):
It looks *useDefaultCcache* is not sufficient on Fedora with IBM JDK defaults.
It works if I set path to the ccache manually by klist output:
{code:java}
options.put("useCcache", "FILE:/tmp/krb5cc_1000");
{code}
> local-kerberos CredentialSource does not work with IBM java
> -----------------------------------------------------------
>
> Key: ELY-1541
> URL: https://issues.jboss.org/browse/ELY-1541
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credentials
> Affects Versions: 1.2.3.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: ibm-java
>
> Why trying to connect as with Oracle JDK, following error follows:
> {code}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: ELY05053: Callback handler failed for unknown reason: java.lang.reflect.UndeclaredThrowableException: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Cannot get credential for principal default principal
> {code}
> This is probably related to missing *useDefaultCcache* JAAS config (false by default):
> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_6.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1541) local-kerberos CredentialSource does not work with IBM java
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1541?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1541:
---------------------------------
Also direct username+password for kerberos account can be passed into Kerberos - maybe we should allow this with AuthenticationContext callback handler:
{code:java}
LoginContext lc = new LoginContext("KDC", subject, (callbacks) -> {
// can be ommited if credential present in ccache
for (Callback c : callbacks) {
if (c instanceof NameCallback) {
((NameCallback)c).setName("hnelson(a)JBOSS.ORG");
} else if (c instanceof PasswordCallback) {
((PasswordCallback)c).setPassword("secret".toCharArray());
} else {
throw new UnsupportedCallbackException(c);
}
}
}, configuration);
{code}
> local-kerberos CredentialSource does not work with IBM java
> -----------------------------------------------------------
>
> Key: ELY-1541
> URL: https://issues.jboss.org/browse/ELY-1541
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credentials
> Affects Versions: 1.2.3.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: ibm-java
>
> Why trying to connect as with Oracle JDK, following error follows:
> {code}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: ELY05053: Callback handler failed for unknown reason: java.lang.reflect.UndeclaredThrowableException: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Cannot get credential for principal default principal
> {code}
> This is probably related to missing *useDefaultCcache* JAAS config (false by default):
> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_6.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1541) local-kerberos CredentialSource does not work with IBM java
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1541?page=com.atlassian.jira.plugin.s... ]
Jan Kalina commented on ELY-1541:
---------------------------------
It looks *useDefaultCcache* is not sufficient on Fedora with IBM JDK defaults.
It works if I set path to the ccache manually by klist output:
{code:java}
options.put("useCcache", "FILE:/tmp/krb5cc_1000");
{code}
> local-kerberos CredentialSource does not work with IBM java
> -----------------------------------------------------------
>
> Key: ELY-1541
> URL: https://issues.jboss.org/browse/ELY-1541
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credentials
> Affects Versions: 1.2.3.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Labels: ibm-java
>
> Why trying to connect as with Oracle JDK, following error follows:
> {code}
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: ELY05053: Callback handler failed for unknown reason: java.lang.reflect.UndeclaredThrowableException: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Cannot get credential for principal default principal
> {code}
> This is probably related to missing *useDefaultCcache* JAAS config (false by default):
> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_6.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months
[JBoss JIRA] (ELY-1418) CLIENT_CERT without users certificates database
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1418?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1418:
-----------------------------------
[~bilge][~fjuma] [~bmaxwell] Can we discuss possibility of creating RFE for this.
Customers migrating from legacy security solution are missing this feature. Although they can write custom realm, I think it would be more convenient if Elytron provide support for this out of the box.
> CLIENT_CERT without users certificates database
> -----------------------------------------------
>
> Key: ELY-1418
> URL: https://issues.jboss.org/browse/ELY-1418
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: HTTP
> Affects Versions: 1.2.0.Beta7
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> CLIENT_CERT http-authentication-mechanism currently requires to provide security-realm, which will contain identity for given certificate and will verify X509Evidence for it. This does not provide replacement for legacy truststore auth, which allows to use only CA certificate to authenticate users by certificates signed by CA, without any database of them.
> Analysis document:
> https://developer.jboss.org/wiki/AnalysisDesign-CLIENTCERTWithoutUsersCer...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 4 months