August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12451) Upgrade WildFly Core to 10.0.0.Beta5

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12451: --------------------------------------- Summary: Upgrade WildFly Core to 10.0.0.Beta5 Key: WFLY-12451 URL: https://issues.jboss.org/browse/WFLY-12451 Project: WildFly Issue Type: Component Upgrade Components: Server Reporter: Brian Stansberry Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12450) Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CR1

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12450?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12450: ------------------------------------ Summary: Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CR1 (was: Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CDR1) > Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CR1 > ------------------------------------------------------------ > > Key: WFLY-12450 > URL: https://issues.jboss.org/browse/WFLY-12450 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12450) Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CDR1

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12450: --------------------------------------- Summary: Upgrade jboss-jms-api_2.0_spec from 1.0.2.Final to 2.0.0.CDR1 Key: WFLY-12450 URL: https://issues.jboss.org/browse/WFLY-12450 Project: WildFly Issue Type: Sub-task Components: JMS Reporter: Brian Stansberry Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky edited comment on JGRP-2274 at 8/28/19 7:53 PM: -------------------------------------------------------------- [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. This is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP/TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? was (Author: nsawadsky): [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP/TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? > ASYM_ENCRYPT: deprecate sign_msgs > --------------------------------- > > Key: JGRP-2274 > URL: https://issues.jboss.org/browse/JGRP-2274 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.12 > > > In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. > However, this is redundant, as decryption of a message will fail if the contents have been changed. > If needed, signing of messages can be done in a separate protocol. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky commented on JGRP-2274: ------------------------------------- [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP or TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? > ASYM_ENCRYPT: deprecate sign_msgs > --------------------------------- > > Key: JGRP-2274 > URL: https://issues.jboss.org/browse/JGRP-2274 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.12 > > > In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. > However, this is redundant, as decryption of a message will fail if the contents have been changed. > If needed, signing of messages can be done in a separate protocol. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2274?page=com.atlassian.jira.plugin.... ] Nick Sawadsky edited comment on JGRP-2274 at 8/28/19 7:52 PM: -------------------------------------------------------------- [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP/TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? was (Author: nsawadsky): [~belaban] I have spent some time looking into GCM support and came to the conclusion it might not be the best fit for this purpose. The challenge with GCM is the strict requirement not to reuse the same IV with the same key. In a JGroups cluster, with many nodes sending messages encrypted with the same key, this is a difficult constraint to enforce. So a separate INTEGRITY protocol, based on HMAC, might be a better way to go. Perhaps combined with CBC support in Encrypt, to get off of ECB. Which is starting to feel like more than I can tackle at this point in time. Another approach to securing the cluster communications would be adding support for TLS in TCP or TCP_NIO2. This would cover both encryption, authentication, and integrity in a standards-based way. Just wondering -- is this something that is currently on the near-term or long-term roadmap? > ASYM_ENCRYPT: deprecate sign_msgs > --------------------------------- > > Key: JGRP-2274 > URL: https://issues.jboss.org/browse/JGRP-2274 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.0.12 > > > In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature. > However, this is redundant, as decryption of a message will fail if the contents have been changed. > If needed, signing of messages can be done in a separate protocol. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12360) Upgrade org.jboss.spec.javax.el from 1.0.13.Final to 2.0.0.Final

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-12360?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-12360: ------------------------------------- initial pr [https://github.com/wildfly/wildfly/pull/12552] > Upgrade org.jboss.spec.javax.el from 1.0.13.Final to 2.0.0.Final > ---------------------------------------------------------------- > > Key: WFLY-12360 > URL: https://issues.jboss.org/browse/WFLY-12360 > Project: WildFly > Issue Type: Sub-task > Components: EE > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Critical > Fix For: 18.0.0.Beta1 > > > JBoss Jakarta Expression Language API: > https://github.com/jboss/jboss-jakarta-el-api_spec -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12449) Update jboss-jakarta-ejb-api_spec to 2.0.0.CR1

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-12449: ------------------------------------- Summary: Update jboss-jakarta-ejb-api_spec to 2.0.0.CR1 Key: WFLY-12449 URL: https://issues.jboss.org/browse/WFLY-12449 Project: WildFly Issue Type: Sub-task Components: EJB Reporter: Tomasz Adamski Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12449) Update jboss-jakarta-ejb-api_spec to 2.0.0.CR1

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-12449?page=com.atlassian.jira.plugin... ] Tomasz Adamski reassigned WFLY-12449: ------------------------------------- Assignee: Tomasz Adamski (was: Cheng Fang) > Update jboss-jakarta-ejb-api_spec to 2.0.0.CR1 > ---------------------------------------------- > > Key: WFLY-12449 > URL: https://issues.jboss.org/browse/WFLY-12449 > Project: WildFly > Issue Type: Sub-task > Components: EJB > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4635) Introduce multiple overloads of CapabilityServiceBuilder.provides() method

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4635?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFCORE-4635: ----------------------------------- Summary: Introduce multiple overloads of CapabilityServiceBuilder.provides() method (was: Introduce CapabilityServiceBuilder.provides(RuntimeCapability<?> c, ServiceName... ns) method) > Introduce multiple overloads of CapabilityServiceBuilder.provides() method > -------------------------------------------------------------------------- > > Key: WFCORE-4635 > URL: https://issues.jboss.org/browse/WFCORE-4635 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 10.0.0.Beta5 > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 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 August 2019