October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11887) [CVE-2016-3720]: Usage of vulnarable Jackson 1.9.13 libraries

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11887: ------------------------------------ Security: (was: Security Issue) > [CVE-2016-3720]: Usage of vulnarable Jackson 1.9.13 libraries > ------------------------------------------------------------- > > Key: WFLY-11887 > URL: https://issues.jboss.org/browse/WFLY-11887 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 14.0.0.Final > Reporter: Radoslav Ivanov > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 18.0.0.Final > > > We have a couple of high prio vulnerabilities reported around usage of Jackson libraries on WildFly with regards to CVE-2016-3720: > {code:java} > jackson-core-asl-1.9.13.jar > jackson-jaxrs-1.9.13.jar > jackson-mapper-asl-1.9.13.jar > jackson-xc-1.9.13.jar > {code} > Could you please review and remove/update them? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12628) Downgrade MicroProfile Health to 2.0.1

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12628?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12628: ------------------------------------ Priority: Blocker (was: Major) > Downgrade MicroProfile Health to 2.0.1 > -------------------------------------- > > Key: WFLY-12628 > URL: https://issues.jboss.org/browse/WFLY-12628 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Health > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 18.0.0.Final > > > MP Health was upgraded to 2.1 in WFLY-12555 at the same time that smallrye-health was upgrade to 2.0.0 in WFLY-12554 > That was a mistake as smallrye-health is depending on MP Health 2.0.1. > There is no harm on staying on MP Health 2.1 as the API changes are internal to the API and do not require any implementation from the provider: > https://github.com/eclipse/microprofile-health/compare/2.0.1...2.1 > However, if we decide to keep WildFly 18 under the same MP Umbrella release (3.0) at the moment, it might be better to downgrade to 2.0.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12628) Downgrade MicroProfile Health to 2.0.1

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12628?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12628: ------------------------------------ Fix Version/s: 18.0.0.Final > Downgrade MicroProfile Health to 2.0.1 > -------------------------------------- > > Key: WFLY-12628 > URL: https://issues.jboss.org/browse/WFLY-12628 > Project: WildFly > Issue Type: Component Upgrade > Components: MP Health > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 18.0.0.Final > > > MP Health was upgraded to 2.1 in WFLY-12555 at the same time that smallrye-health was upgrade to 2.0.0 in WFLY-12554 > That was a mistake as smallrye-health is depending on MP Health 2.0.1. > There is no harm on staying on MP Health 2.1 as the API changes are internal to the API and do not require any implementation from the provider: > https://github.com/eclipse/microprofile-health/compare/2.0.1...2.1 > However, if we decide to keep WildFly 18 under the same MP Umbrella release (3.0) at the moment, it might be better to downgrade to 2.0.1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12348) JPA statistics fix (WFLY-10964) should be applied to JPA 2.1 as well

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-12348?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-12348: ------------------------------------- The [https://github.com/hibernate/hibernate-orm/tree/master/hibernate-jipijapa...] is a fork, I wanted to move all of the Hibernate integration code there, but I found out after that being discussed, that we needed to keep that code in WildFly, for addressing clustering issues. So, the Hibernate copy of that code, is a mostly for the Hibernate testsuite but could possibly be used by some users. The sources in Hibernate use tabs instead of spaces and have other cosmetic differences. I can mention some steps that you could take to sync changes made in WildFly with the forked code in the Hibernate project, if your interested in creating a Hibernate ORM pull request for that. Could you please verify that [https://github.com/scottmarlow/wildfly/tree/WFLY-12348_jpa2.1] contains the changes that you had in mind and work for you? I'll create a pull request for the change after I hear back from you. Thanks for reporting this! Scott > JPA statistics fix (WFLY-10964) should be applied to JPA 2.1 as well > -------------------------------------------------------------------- > > Key: WFLY-12348 > URL: https://issues.jboss.org/browse/WFLY-12348 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 17.0.1.Final > Reporter: Jippe Holwerda > Assignee: Scott Marlow > Priority: Major > > Microprofile Metrics in Wildfly 17.0.1 in combination with JPA 2.1 is currently broken. The fix done in WFLY-10964 (https://github.com/wildfly/wildfly/commit/9dac9810796469ab45cb2b6e0fde926...) should be applied to the JPA 2.1 version (wildfly/jpa/hibernate5) as well. > Also, the same faulty code is present in Hibernate: https://github.com/hibernate/hibernate-orm/tree/master/hibernate-jipijapa... > Not sure why it is in there as well, but it probably should be fixed or removed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2386) Support for encryption ciphers that require an initialization vector

by Nick Sawadsky (Jira)

[ https://issues.jboss.org/browse/JGRP-2386?page=com.atlassian.jira.plugin.... ] Nick Sawadsky commented on JGRP-2386: ------------------------------------- Thanks [~belaban]! Linking the pull request: https://github.com/belaban/JGroups/pull/441 > Support for encryption ciphers that require an initialization vector > -------------------------------------------------------------------- > > Key: JGRP-2386 > URL: https://issues.jboss.org/browse/JGRP-2386 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.5, 3.6.19 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > Fix For: 4.1.6 > > > By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. > Modes like CBC, that use a random initialization vector (IV) avoid this problem (assuming a different IV is used for each message). > It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12629) MicroProfile capability names are mangled "org.wildlfy..."

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-12629?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-12629: ---------------------------------- Description: Namely: org.wildlfy.microprofile.config org.wildlfy.microprofile.health.reporter org.wildlfy.extension.microprofile.metrics.wildfly-collector Lets fix these up before we properly support this since WF 19. was: Namely: org.wildlfy.microprofile.config org.wildlfy.microprofile.health.reporter org.wildlfy.extension.microprofile.metrics.wildfly-collector > MicroProfile capability names are mangled "org.wildlfy..." > ---------------------------------------------------------- > > Key: WFLY-12629 > URL: https://issues.jboss.org/browse/WFLY-12629 > Project: WildFly > Issue Type: Bug > Components: MP Config, MP Health, MP Metrics > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > Namely: > org.wildlfy.microprofile.config > org.wildlfy.microprofile.health.reporter > org.wildlfy.extension.microprofile.metrics.wildfly-collector > Lets fix these up before we properly support this since WF 19. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12629) MicroProfile capability names are mangled "org.wildlfy..."

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-12629: ------------------------------------- Summary: MicroProfile capability names are mangled "org.wildlfy..." Key: WFLY-12629 URL: https://issues.jboss.org/browse/WFLY-12629 Project: WildFly Issue Type: Bug Components: MP Config, MP Health, MP Metrics Reporter: Radoslav Husar Assignee: Radoslav Husar Namely: org.wildlfy.microprofile.config org.wildlfy.microprofile.health.reporter org.wildlfy.extension.microprofile.metrics.wildfly-collector -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-12614) Duplicated ConstraintViolation message

by Ronald Sigal (Jira)

[ https://issues.jboss.org/browse/WFLY-12614?page=com.atlassian.jira.plugin... ] Ronald Sigal commented on WFLY-12614: ------------------------------------- [~brian.stansberry], I did the validation integration years ago, which has some peculiar twists and turns, mainly because of CDI interfering with the order of things. I've tracked down edge cases over the years, so much so that I'm reminded of Captain Ahab: "He tasks me; he heaps me; I see in him outrageous strength, with an inscrutable malice sinewing it." ;-) I'll take a look. > Duplicated ConstraintViolation message > -------------------------------------- > > Key: WFLY-12614 > URL: https://issues.jboss.org/browse/WFLY-12614 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 17.0.1.Final, 18.0.0.Beta1 > Reporter: Robin Schimpf > Assignee: Alessio Soldano > Priority: Major > Attachments: wildfly-bug.zip > > > We currently are upgrading our application from Wildfly 13 to Wildfly 17.0.1 and are receiving duplicated constraint violations in the response of an invalid request. > Interestingly Wildfly 13 also seems to be not behaving correctly on the third request but in another way. There is the violation exception returned in the response instead of the duplicated value Wildfly 17 is returning now. > I also tested this on the currently available Wildfly 18 Beta 1 and the issue is also reproducible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-962) Implement Resource Ready best practice

by Filip Brychta (Jira)

Filip Brychta created SWSQE-962: ----------------------------------- Summary: Implement Resource Ready best practice Key: SWSQE-962 URL: https://issues.jboss.org/browse/SWSQE-962 Project: Kiali QE Issue Type: Story Reporter: Filip Brychta Assignee: Filip Brychta According to QE CI best practice [1] it should be possible to use a gating mechanism which is checking availability of required resources before starting job. We could maybe use it for: * OCP cluster is UP * UMB is accessible * etc [1] - https://docs.engineering.redhat.com/display/QEARCH/Resource+Ready -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFWIP-189: ----------------------------------- This problem is not specific to the operator and is something inherent to Kubernetes. There are various approaches to mitigate this issue and they all seem ad hoc... The solution mentioned in https://blog.questionable.services/article/kubernetes-deployments-configm... is not sufficient. It requires to watch for any config map / secrets that the application references and compute their checksum and put that info in the WildFlyServer resources. This goes beyond what the operator should deal with (and still leaves some windows that would result in inconsistencies between pods). As far as I can tell the best way to mitigate that issue is to "version" the names of the config maps referenced by the operator. Eg. {code} spec: envFrom: - configMapRef: name: my-config-1 {code} If a change must be made to the config map, it can be copied to another config map named config-2. Then the WildFlyServer Spec can be updated with that info: {code} spec: envFrom: - configMapRef: name: my-config-2 {code} I don't think the operator should change the semantic and behaviour of the existing Kubernetes resources. it should comply with it and works in a way that is consistent with Kubernetes. It is known that updating a config map will not trigger a rollout of a deployment (even more so any change in a statefulset). > Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies > ------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-189 > URL: https://issues.jboss.org/browse/WFWIP-189 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Petr Kremensky > Assignee: Jeff Mesnil > Priority: Blocker > Labels: operator > > User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blo...] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them). > The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configm... > *reproduce* > * create a config map with ("foo1", "bar1") entry > * create an operator (size = 1) with a reference to the config map > * update the config map - add ("foo2", "bar2") entry > * resize the operator > *actual* > {code} > $ oc get pods > NAME READY STATUS RESTARTS AGE > eap-cd-0 1/1 Running 0 112s > eap-cd-1 1/1 Running 0 94s > wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s > $ oc rsh pod/eap-cd-0 > sh-4.4$ env | grep foo > foo1=bar1 > $ oc rsh pod/eap-cd-1 > sh-4.4$ env | grep foo > foo1=bar1 > foo2=bar2 > {code} > *expected* > {code} > $ oc get pods > NAME READY STATUS RESTARTS AGE > eap-cd-0 1/1 Running 0 112s > eap-cd-1 1/1 Running 0 94s > wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s > $ oc rsh pod/eap-cd-0 > sh-4.4$ env | grep foo > foo1=bar1 > foo2=bar2 > $ oc rsh pod/eap-cd-1 > sh-4.4$ env | grep foo > foo1=bar1 > foo2=bar2 > {code} > *Environment:* > *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102...] > *openshift version:* > {noformat} > OpenShift version: 4.1.11 > Kubernetes Master Version: v1.13.4+df9cebc > {noformat} > Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019