April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1561) TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1561?page=com.atlassian.jira.plugin.s... ] Martin Choma commented on ELY-1561: ----------------------------------- And did you encounter any problem in this area or you just noticed? So for we have not noticed any problem of this kind during testing. > TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1561 > URL: https://issues.jboss.org/browse/ELY-1561 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.8.CR1, 1.3.0.CR1, 1.2.5.CR1 > > > The TCCL is not set, so the chances of finding {{com.sun.security.auth.module.Krb5LoginModule}} or {{com.ibm.security.auth.module.Krb5LoginModule}} are essentially completely dependent on the environment. However since the class is always the same, and we can safely assume that we should have a dependency on that module, we should set TCCL around the initialization of the {{LoginContext}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1561) TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1561?page=com.atlassian.jira.plugin.s... ] Martin Choma edited comment on ELY-1561 at 4/12/18 1:45 AM: ------------------------------------------------------------ And did you encounter any problem in this area or you just noticed? So far we have not noticed any problem of this kind during testing. was (Author: mchoma): And did you encounter any problem in this area or you just noticed? So for we have not noticed any problem of this kind during testing. > TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1561 > URL: https://issues.jboss.org/browse/ELY-1561 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.8.CR1, 1.3.0.CR1, 1.2.5.CR1 > > > The TCCL is not set, so the chances of finding {{com.sun.security.auth.module.Krb5LoginModule}} or {{com.ibm.security.auth.module.Krb5LoginModule}} are essentially completely dependent on the environment. However since the class is always the same, and we can safely assume that we should have a dependency on that module, we should set TCCL around the initialization of the {{LoginContext}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3734) [Coverity] Operation - Potential Resource Leak

by Rostislav Svoboda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3734?page=com.atlassian.jira.plugi... ] Rostislav Svoboda updated WFCORE-3734: -------------------------------------- Priority: Major (was: Critical) > [Coverity] Operation - Potential Resource Leak > ----------------------------------------------- > > Key: WFCORE-3734 > URL: https://issues.jboss.org/browse/WFCORE-3734 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Martin Choma > Assignee: Brian Stansberry > > Closeable Operation is not closed in: > * {code:java|title=ModelControllerClientFactoryImpl.java} > private OperationResponse runOperation(final ModelNode operation, final OperationMessageHandler messageHandler, > final OperationAttachments attachments, boolean inVmCall) { > Operation op = attachments == null ? Operation.Factory.create(operation) : Operation.Factory.create(operation, attachments.getInputStreams(), > attachments.isAutoCloseStreams()); > if (inVmCall) { > return SecurityActions.runInVm(() -> modelController.execute(op, messageHandler, ModelController.OperationTransactionControl.COMMIT)); > } else { > return modelController.execute(op, messageHandler, ModelController.OperationTransactionControl.COMMIT); > } > } > {code} > * {code:java|title=AffectedDeploymentOverlay.java} > final ModelNode slave = opBuilder.build().getOperation(); > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3737) Upgrade to openssl from 1.0.4.Final to 1.0.6.Final or newer

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3737?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-14598 to WFCORE-3737: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3737 (was: JBEAP-14598) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Web (Undertow)) Fix Version/s: (was: 7.1.3.GA) > Upgrade to openssl from 1.0.4.Final to 1.0.6.Final or newer > ----------------------------------------------------------- > > Key: WFCORE-3737 > URL: https://issues.jboss.org/browse/WFCORE-3737 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Chao Wang > Assignee: Stuart Douglas > > https://github.com/wildfly/wildfly-openssl/compare/1.0.2.Final...1.0.6.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3736) Remove sparc support from OpenSSL native bindings

by Stuart Douglas (JIRA)

Stuart Douglas created WFCORE-3736: -------------------------------------- Summary: Remove sparc support from OpenSSL native bindings Key: WFCORE-3736 URL: https://issues.jboss.org/browse/WFCORE-3736 Project: WildFly Core Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1561) TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1561?page=com.atlassian.jira.plugin.s... ] David Lloyd updated ELY-1561: ----------------------------- Fix Version/s: 1.1.8.CR1 1.3.0.CR1 1.2.5.CR1 > TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1561 > URL: https://issues.jboss.org/browse/ELY-1561 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.8.CR1, 1.3.0.CR1, 1.2.5.CR1 > > > The TCCL is not set, so the chances of finding {{com.sun.security.auth.module.Krb5LoginModule}} or {{com.ibm.security.auth.module.Krb5LoginModule}} are essentially completely dependent on the environment. However since the class is always the same, and we can safely assume that we should have a dependency on that module, we should set TCCL around the initialization of the {{LoginContext}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1562) TCCL not set around InitialLdapContext ctor in SimpleDirContextFactory#createDirContext

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1562?page=com.atlassian.jira.plugin.s... ] David Lloyd closed ELY-1562. ---------------------------- Resolution: Rejected This is incorrect; the TCCL is indeed set. > TCCL not set around InitialLdapContext ctor in SimpleDirContextFactory#createDirContext > --------------------------------------------------------------------------------------- > > Key: ELY-1562 > URL: https://issues.jboss.org/browse/ELY-1562 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Reporter: David Lloyd > Assignee: David Lloyd > > The TCCL is not set even though the implementation class is known and static. Similar to ELY-1561. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1562) TCCL not set around InitialLdapContext ctor in SimpleDirContextFactory#createDirContext

by David Lloyd (JIRA)

David Lloyd created ELY-1562: -------------------------------- Summary: TCCL not set around InitialLdapContext ctor in SimpleDirContextFactory#createDirContext Key: ELY-1562 URL: https://issues.jboss.org/browse/ELY-1562 Project: WildFly Elytron Issue Type: Bug Components: Realms Reporter: David Lloyd Assignee: David Lloyd The TCCL is not set even though the implementation class is known and static. Similar to ELY-1561. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1561) TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential

by David Lloyd (JIRA)

David Lloyd created ELY-1561: -------------------------------- Summary: TCCL not set around LoginContext ctor call in GSSCredentialSecurityFactory.Builder#createGSSCredential Key: ELY-1561 URL: https://issues.jboss.org/browse/ELY-1561 Project: WildFly Elytron Issue Type: Bug Components: Authentication Mechanisms Reporter: David Lloyd Assignee: David Lloyd The TCCL is not set, so the chances of finding {{com.sun.security.auth.module.Krb5LoginModule}} or {{com.ibm.security.auth.module.Krb5LoginModule}} are essentially completely dependent on the environment. However since the class is always the same, and we can safely assume that we should have a dependency on that module, we should set TCCL around the initialization of the {{LoginContext}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10200) WARN on presence of -jms.xml file if embedded broker is not present, instead of doing invalid wiring

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10200?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-10200: ------------------------------------ Description: This is largely a topic for discussion. If the messaging subsystem is present but no 'server' child resource is installed, there's a DUP that will try and create services for destinations in any discovered xxx-jms.xml. These will fail due to missing dependencies on broker services. Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the destinations configured in the -jms.xml and they are not provided otherwise (i.e. separately configured on an external broker) then the app will fail anyway, and the WARN would just help explain why. But if the destinations are available, then the -jms.xml could be regarded as just ignorable cruft left in the deployment. For example, the app at https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-... could benefit from this, by being able to work when deployed 1) with an embedded broker or 2) with an external broker and just an empty subsystem-messaging-activemq. An assumption I'm making here is a subsystem=messaging-activemq is or will be useful even without a child 'server' resource. That's what our current openshift images configure when we configure for an external broker. was: This is largely a topic for discussion. If the messaging subsystem is present but no 'server' child resource is installed, there's a DUP that will try and create services for destinations in any discovered xxx-jmx.xml. These will fail due to missing dependencies on broker services. Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the destinations configured in the -jmx.xml and they are not provided otherwise (i.e. separately configured on an external broker) then the app will fail anyway, and the WARN would just help explain why. But if the destinations are available, then the -jms.xml could be regarded as just ignorable cruft left in the deployment. For example, the app at https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-... could benefit from this, by being able to work when deployed 1) with an embedded broker or 2) with an external broker and just an empty subsystem-messaging-activemq. An assumption I'm making here is a subsystem=messaging-activemq is or will be useful even without a child 'server' resource. That's what our current openshift images configure when we configure for an external broker. > WARN on presence of -jms.xml file if embedded broker is not present, instead of doing invalid wiring > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-10200 > URL: https://issues.jboss.org/browse/WFLY-10200 > Project: WildFly > Issue Type: Enhancement > Components: JMS > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Minor > > This is largely a topic for discussion. > If the messaging subsystem is present but no 'server' child resource is installed, there's a DUP that will try and create services for destinations in any discovered xxx-jms.xml. These will fail due to missing dependencies on broker services. > Perhaps the DUP could just log a WARN in this case. Of course if the app depends on the destinations configured in the -jms.xml and they are not provided otherwise (i.e. separately configured on an external broker) then the app will fail anyway, and the WARN would just help explain why. But if the destinations are available, then the -jms.xml could be regarded as just ignorable cruft left in the deployment. > For example, the app at https://github.com/jboss-openshift/openshift-quickstarts/tree/master/jta-... could benefit from this, by being able to work when deployed 1) with an embedded broker or 2) with an external broker and just an empty subsystem-messaging-activemq. > An assumption I'm making here is a subsystem=messaging-activemq is or will be useful even without a child 'server' resource. That's what our current openshift images configure when we configure for an external broker. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 April 2018