February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8104) Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem)

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8104?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-8104: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem) > -------------------------------------------------------------------------------------------- > > Key: WFLY-8104 > URL: https://issues.jboss.org/browse/WFLY-8104 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > Coverity found 2 possible occurences of dereferencing null. > https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644... > https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644... > {code:java} > private char[] resolvePassword() throws Exception { > ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue(); > CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null; > if (cs != null) { > return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword(); > } else { > throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath()); > } > } > {code} > Both {{getCredential(Class<C> credentialType)}} and {{getPassword(Class<P> type)}} have in javadoc mentioned return value can be null. > Also in org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder.SimpleDirContextFactory.obtainDirContext(org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode) returned value are explicitely checked on null value. > Add null check also in {{resolvePassword()}} method -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8114) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-8114: -------------------------------------- Summary: It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor Key: WFLY-8114 URL: https://issues.jboss.org/browse/WFLY-8114 Project: WildFly Issue Type: Bug Components: EJB Reporter: Wolf-Dieter Fink Assignee: David Lloyd With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. Since AS7 and WildFly the only possibility is to pass such context from the client to the server. It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ] Brad Maxwell updated WFLY-1805: ------------------------------- Issue Type: Bug (was: Feature Request) > It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor > ----------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1805 > URL: https://issues.jboss.org/browse/WFLY-1805 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Labels: ejb > > With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors. > Since AS7 and WildFly the only possibility is to pass such context from the client to the server. > It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations. > This was used to return i.e. tracking or additional usefull informations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-963) Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev updated ELY-963: ------------------------------ Affects Version/s: 1.1.0.Beta24 > Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron) > ----------------------------------------------------------------------------------- > > Key: ELY-963 > URL: https://issues.jboss.org/browse/ELY-963 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered. > {code:java} > private X509Certificate getClientCertificate() throws SaslException { > if ((clientCertChain != null) && (clientCertChain.length > 0)) { > return clientCertChain[0]; > } else if (clientCertUrl != null) { > try { > return EntityUtil.getCertificateFromUrl(clientCertUrl); > } catch (IOException e) { > throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException(); > } > } else { > throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException(); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-963) Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-963?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-8107 to ELY-963: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-963 (was: WFLY-8107) Component/s: (was: Security) > Coverity static analysis, Unwritten field, EntitySaslClient.clientCertUrl (Elytron) > ----------------------------------------------------------------------------------- > > Key: ELY-963 > URL: https://issues.jboss.org/browse/ELY-963 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Coverity found field {{EntitySaslClient.clientCertUrl}} is never filled. So probably initially intended behavior in {{X509Certificate getClientCertificate()}} method is not covered. > {code:java} > private X509Certificate getClientCertificate() throws SaslException { > if ((clientCertChain != null) && (clientCertChain.length > 0)) { > return clientCertChain[0]; > } else if (clientCertUrl != null) { > try { > return EntityUtil.getCertificateFromUrl(clientCertUrl); > } catch (IOException e) { > throw log.mechUnableToObtainServerCertificate(getMechanismName(), clientCertUrl.toString(), e).toSaslException(); > } > } else { > throw log.mechCallbackHandlerNotProvidedServerCertificate(getMechanismName()).toSaslException(); > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-962) Coverity: Incorrect definition of Serializable classes *PrivateKey (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-962?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-7968 to ELY-962: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-962 (was: WFLY-7968) Component/s: (was: Security) Affects Version/s: 1.1.0.Beta24 (was: 11.0.0.Alpha1) > Coverity: Incorrect definition of Serializable classes *PrivateKey (Elytron) > ---------------------------------------------------------------------------- > > Key: ELY-962 > URL: https://issues.jboss.org/browse/ELY-962 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > There are couple of classes marked as Serializable, but containing non-serializable fields. > * RawECPrivateKey > * RawDHPrivateKey > * RawDSAPrivateKey > * RawRSAMultiPrimePrivateCrtKey > Mark non-serializable fields transient or Serializable > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=85539... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7093) Transfer of contextData back to the jboss ejb client

by Wolf-Dieter Fink (JIRA)

[ https://issues.jboss.org/browse/WFLY-7093?page=com.atlassian.jira.plugin.... ] Wolf-Dieter Fink closed WFLY-7093. ---------------------------------- Resolution: Duplicate Issue First is WFLY-1805 > Transfer of contextData back to the jboss ejb client > ---------------------------------------------------- > > Key: WFLY-7093 > URL: https://issues.jboss.org/browse/WFLY-7093 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.1.0.Final > Reporter: Teresa Miyar > Assignee: David Lloyd > Priority: Minor > Attachments: MethodInvocationMessageHandler.java.diff, MethodInvocationResponseHandler.java.diff > > > The spec says: > The getContextData method enables a business method, lifecycle callback method, or timeout method to retrieve any interceptor/webservices context associated with its invocation. > The way this context data travels from client to server is by copying the data into a server context, this data is used inside the server ejb but not copied back to client. Client requests that this contextData is populated from client to server and vice versa. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-961) Coverity: Incorrect definition of RawKey as a parent of Serializable classes

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-961?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-7967 to ELY-961: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-961 (was: WFLY-7967) Component/s: (was: Security) > Coverity: Incorrect definition of RawKey as a parent of Serializable classes > ---------------------------------------------------------------------------- > > Key: ELY-961 > URL: https://issues.jboss.org/browse/ELY-961 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > There are some Serializable classes, which extends from RawKey, which is not Serializable. > * RawRSAPrivateKey > * RawDHPrivateKey > * RawPBEKey > * RawECPrivateKey > * RawDSAPrivateKey > Either mark RawKey as Serializable as well or if this is not desired, provide no-args constructor in RawKey class, as javadoc describes: > ??During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream. [1]?? > [1] http://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=85539... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-961) Coverity: Incorrect definition of RawKey as a parent of Serializable classes

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-961?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev updated ELY-961: ------------------------------ Affects Version/s: 1.1.0.Beta24 > Coverity: Incorrect definition of RawKey as a parent of Serializable classes > ---------------------------------------------------------------------------- > > Key: ELY-961 > URL: https://issues.jboss.org/browse/ELY-961 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > There are some Serializable classes, which extends from RawKey, which is not Serializable. > * RawRSAPrivateKey > * RawDHPrivateKey > * RawPBEKey > * RawECPrivateKey > * RawDSAPrivateKey > Either mark RawKey as Serializable as well or if this is not desired, provide no-args constructor in RawKey class, as javadoc describes: > ??During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream. [1]?? > [1] http://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=85539... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-960) Coverity static analysis: Suspicious integer expression in BSDUnixDESCryptPasswordImpl (Elytron)

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-960?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev moved WFLY-7966 to ELY-960: ----------------------------------------- Project: WildFly Elytron (was: WildFly) Key: ELY-960 (was: WFLY-7966) Component/s: Passwords (was: Security) Affects Version/s: 1.1.0.Beta24 (was: 11.0.0.Alpha1) > Coverity static analysis: Suspicious integer expression in BSDUnixDESCryptPasswordImpl (Elytron) > ------------------------------------------------------------------------------------------------ > > Key: ELY-960 > URL: https://issues.jboss.org/browse/ELY-960 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Affects Versions: 1.1.0.Beta24 > Reporter: Martin Choma > Assignee: Ilia Vassilev > > Seems {{if}} statement will never be {{true}}, because invKeyPerm is of type byte[]. And permitted values for byte are -128...127. > {code:java|title=BSDUnixDESCryptPasswordImpl.java} > outBit = invKeyPerm[inBit]; > if (outBit == 255) { > continue; > } > {code} > https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=85538... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017