October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1420) Release WildFly Elytron 1.2.0.Beta8

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1420: ------------------------------------- Summary: Release WildFly Elytron 1.2.0.Beta8 Key: ELY-1420 URL: https://issues.jboss.org/browse/ELY-1420 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta8 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1419) Release WildFly Elytron 1.1.6.Final

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1419: ------------------------------------- Summary: Release WildFly Elytron 1.1.6.Final Key: ELY-1419 URL: https://issues.jboss.org/browse/ELY-1419 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.6.CR1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1770) FEEL runtime cycle detection false positive

by Fedor Gavrilov (JIRA)

Fedor Gavrilov created DROOLS-1770: -------------------------------------- Summary: FEEL runtime cycle detection false positive Key: DROOLS-1770 URL: https://issues.jboss.org/browse/DROOLS-1770 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.4.0.Final Reporter: Fedor Gavrilov Assignee: Fedor Gavrilov Runtime cycle detecton denies the following valid decision node topology: A depends on B and C B and C depend on D D depends on E The same topology but without E node (=deadly diamond) works well. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3365) Upgrade XNIO to 3.5.4.Final

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3365?page=com.atlassian.jira.plugi... ] David Lloyd updated WFCORE-3365: -------------------------------- Summary: Upgrade XNIO to 3.5.4.Final (was: Upgrade XNIO to 3.5.3.Final) > Upgrade XNIO to 3.5.4.Final > --------------------------- > > Key: WFCORE-3365 > URL: https://issues.jboss.org/browse/WFCORE-3365 > Project: WildFly Core > Issue Type: Component Upgrade > Components: IO > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 4.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3366) Upgrade JBoss Remoting to 5.0.4.Final

by David Lloyd (JIRA)

David Lloyd created WFCORE-3366: ----------------------------------- Summary: Upgrade JBoss Remoting to 5.0.4.Final Key: WFCORE-3366 URL: https://issues.jboss.org/browse/WFCORE-3366 Project: WildFly Core Issue Type: Component Upgrade Components: Remoting Reporter: David Lloyd Assignee: David Lloyd Fix For: 4.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3365) Upgrade XNIO to 3.5.3.Final

by David Lloyd (JIRA)

David Lloyd created WFCORE-3365: ----------------------------------- Summary: Upgrade XNIO to 3.5.3.Final Key: WFCORE-3365 URL: https://issues.jboss.org/browse/WFCORE-3365 Project: WildFly Core Issue Type: Component Upgrade Components: IO Reporter: David Lloyd Assignee: David Lloyd Fix For: 4.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-6823: -------------------------------- Assignee: (was: Jan Kalina) > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-6823: ---------------------------------- The problem is, firefox encodes only least significant byte of the character when converting to ISO-8859-1 - we are unable to convert back to unicode character as the information from previous bytes of the character is missing - we would have to store passwords in hash trimmed too, or we would have to store them plain, which is not acceptable for production usage. This is not problem of charset - the information is already missing in firefox response. -> dev nacked > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Jan Kalina > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-6823: -------------------------------- Assignee: Jan Kalina > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Jan Kalina > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1769) All release branches should be protected from a force push

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1769?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer commented on DROOLS-1769: ------------------------------------------------ response of GitHub guys: Hi Michael, my question was: if it is possible to protects automatically new created reps and it's branches in our organization. === Thanks for reaching out to GitHub Support! I'm afraid that isn't currently possible. This sounds like it could be pretty useful so I've added your suggestion to our internal Feature Request List. I can't promise that we will implement this feature now or in the future, but your feedback has definitely been noted and is super appreciated. Cheers, John GitHub Support > All release branches should be protected from a force push > ---------------------------------------------------------- > > Key: DROOLS-1769 > URL: https://issues.jboss.org/browse/DROOLS-1769 > Project: Drools > Issue Type: Enhancement > Components: build > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > There are 2 ways to protect a GitHub repository/branch from force pushing: > 1) a backend switch (not available in their UI) to disable force pushing for the entire repo (OLD) > 2) "protected branches" in the "settings" menu of each repo, in the submenu "branches". > Some repositories, such as "drools" and "optaplanner", have 1), so all their branches are immune to force pushing. > Newer repositories, such as "optaplanner-wb" probably don't have 1). > All repositories seem to have 2) for the following branches: master, 6.4.x, 6.5.x. > BUT NOT 7.3.x etc. That's wrong: this means optaplanner-wb's 7.3.x branch is not protected against force pushes. > All release branches (7.0.x, 7.1.x, ...) should be protected against force pushing. This includes future release branches, so the release procedure should be adjusted accordingly. > We should ask github if there's a way to automatically add all new branches to "protected branches". -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 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 October 2017