date:20170815

Re: [VOTE] Release Tobago 3.0.5

2017-08-15 Thread Udo Schnurpfeil

Hi,

thank you for checking and voting for the release. The result is

+1
Henning Nöth
Dennis Kieselhorst
Bernd Bohmann
Mike Kienenberger

so I will proceed with the next steps for the release.

Regards,

Udo

Am 15.08.17 um 21:40 schrieb Mike Kienenberger:
> - signatures and checksums match
> - source builds
> - apache rat passes
> 
> +1
> 
> 
> 
> Below are the linux commands I used to verify the release of the
> tobago-3.0.5 files:
> 
> =
> 
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.asc
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.md5
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.sha1
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.asc
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.md5
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.sha1
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.asc
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.md5
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.sha1
> 
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.asc
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.md5
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.sha1
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.asc
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.md5
> wget 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.sha1
> 
> # check checksums
> find . -name '*.md5' -exec cat {} \; -printf '  %f\n' | sed
> 's|\.md5$||' | md5sum -c
> find . -name '*.sha1' -exec cat {} \; -printf '  %f\n' | sed
> 's|\.sha1$||' | sha1sum -c
> 
> # check signatures
> wget http://www.apache.org/dist/myfaces/KEYS
> gpg --import KEYS
> find . -name '*.asc' -exec gpg --verify {} \;
> 
> # build source
> mkdir src
> cd src
> unzip ../tobago-3.0.5-source-release.zip
> cd tobago-3.0.5
> mvn install -Pall-modules
> 
> mvn apache-rat:check -Pall-modules
> 
> # To check for all errors, if more than one project is affected
> #   mvn apache-rat:check -Drat.numUnapprovedLicenses=
> # To see details of rat failure, including location of rat report
> #   mvn -e -X apache-rat:check
> 
> 
> # verify tobago-assembly-*-dist.tar.gz and tobago-assembly-*-dist.zip
> binaries are identical
> # verify tobago-example-assembly-*-example.tar.gz and
> tobago-example-assembly-*-example.zip binaries are identical
> 
> cd ..
> 
> tar xvf ../tobago-assembly-3.0.5-dist.tar.gz
> mv myfaces-tobago-3.0.5/

Re: [VOTE] Release Tobago 3.0.5

2017-08-15 Thread Mike Kienenberger

- signatures and checksums match
- source builds
- apache rat passes

+1



Below are the linux commands I used to verify the release of the
tobago-3.0.5 files:

=

wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.md5
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago/3.0.5/tobago-3.0.5-source-release.zip.sha1
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.asc
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.md5
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.tar.gz.sha1
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.md5
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-assembly/3.0.5/tobago-assembly-3.0.5-dist.zip.sha1

wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.asc
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.md5
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.tar.gz.sha1
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.asc
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.md5
wget 
https://repository.apache.org/content/repositories/orgapachemyfaces-1117/org/apache/myfaces/tobago/tobago-example-assembly/3.0.5/tobago-example-assembly-3.0.5-example.zip.sha1

# check checksums
find . -name '*.md5' -exec cat {} \; -printf '  %f\n' | sed
's|\.md5$||' | md5sum -c
find . -name '*.sha1' -exec cat {} \; -printf '  %f\n' | sed
's|\.sha1$||' | sha1sum -c

# check signatures
wget http://www.apache.org/dist/myfaces/KEYS
gpg --import KEYS
find . -name '*.asc' -exec gpg --verify {} \;

# build source
mkdir src
cd src
unzip ../tobago-3.0.5-source-release.zip
cd tobago-3.0.5
mvn install -Pall-modules

mvn apache-rat:check -Pall-modules

# To check for all errors, if more than one project is affected
#   mvn apache-rat:check -Drat.numUnapprovedLicenses=
# To see details of rat failure, including location of rat report
#   mvn -e -X apache-rat:check


# verify tobago-assembly-*-dist.tar.gz and tobago-assembly-*-dist.zip
binaries are identical
# verify tobago-example-assembly-*-example.tar.gz and
tobago-example-assembly-*-example.zip binaries are identical

cd ..

tar xvf ../tobago-assembly-3.0.5-dist.tar.gz
mv myfaces-tobago-3.0.5/ myfaces-tobago-3.0.5.tar.gz.unpacked
unzip ../tobago-assembly-3.0.5-dist.zip
mv myfaces-tobago-3.0.5/ myfaces-tobago-3.0.5.zip.unpacked

tar xvf ../tobago-example-assembly-3.0.5-example.tar.gz
mv myfaces-tobago-3.0.5/ myfaces-tobago-example-3.0.5.tar.gz.unpacked
unzip ../tobago-example-assembly-3.0.5-example.zip
mv myfaces-tobago-3.0.5/ myfaces-tobago-example-3.0.5.zip.unpacked

# should be no output
diff -rq

Re: Issue with injection in ActionListener JSF Artifact

2017-08-15 Thread Eduardo B

When we register an ActionListener or PhaseListener globally via
faces-config.xml, the instance that is created per listener is injectable,
that is, we can do @Inject in the instance. These listeners are added to
the injected bean storage list in the application map and as a result, we
can call @PreDestroy and @PostConstruct on this scenario.

On the other hand, when facelet elements  and
 are used, the instances that are created (per click for
action listener or per view for phase listener) are not injectable. That
is, we cannot do @Inject inside of these objects. And @PreDestroy and
@PostConstruct are not invoked on them.

I supposes we want to have the same behavior in both cases.

To solve this issue, we can probably do a similar logic as what was done in
FacesConfigurator that we call inject on the instance, and then store that
in the injected bean storage list. We can add that logic in the
ActionListenerHandler and PhaseListenerHandler classes after the instance
is created.

// Code snippet

instance = (ActionListener) ReflectionUtil.forName(this.type).newInstance();

ExternalContext externalContext = faces.getExternalContext();

// Note that we have to make INJECTED_BEAN_STORAGE_KEY public

List injectedBeanStorage =
(List)externalContext.getApplicationMap()

.get(FacesConfigurator.INJECTED_BEAN_STORAGE_KEY);

InjectionProvider injectionProvider =
InjectionProviderFactory.getInjectionProviderFactory(

externalContext).getInjectionProvider(externalContext);

Object creationMetaData = injectionProvider.inject(instance);

injectedBeanStorage.add(new BeanEntry(instance, creationMetaData));

injectionProvider.postConstruct(instance, creationMetaData);

But there is an issue when adding that. Every time we use
 with type defined but no binding, a new instance is
created on every button click, the same will happen with
. These instances are added to the list of injected bean
storage, and that reference will exist until app shuts down, creating a *memory
leak*. So we need a way to remove those references from the list once we
are out of scope. We might need a different list for this case. Any
comments will be appreciated.

On Fri, Aug 11, 2017 at 5:19 PM, Eduardo B  wrote:

> In the specs, section 5.4.1 talks about the JSF Artifacts that are
> eligible for Injection.
>
> I tried testing it on Mojarra but couldn't get it to work. I couldn't even
> get to work other JSF Artifacts on Mojarra, so I'm not sure if they support
> all the objects specified in section 5.4.1 or if I'm missing some kind of
> configuration.
>
> On Fri, Aug 11, 2017 at 4:57 PM, Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
>> Not sure.
>> Does it work in Mojarra or did you check the specs?
>>
>> 2017-08-11 22:44 GMT+02:00 Eduardo B :
>>
>>> I have encountered an issue with injection on a JSF Artifact. The
>>> scenario is as follows:
>>>
>>> When a class implements ActionListener, and that action listener is
>>> invoked from a facelet as the snippet below:
>>>
>>> 
>>>
>>> 
>>>
>>> >> />
>>>
>>> 
>>>
>>> 
>>>
>>> The behavior I’m seeing is that we cannot do @Inject on the class that
>>> implements the ActionListener, and @PreDestroy is not being invoked on app
>>> shut down. However, if we register the action listener in the
>>> faces-config.xml, I can see that injection is possible.
>>>
>>> Is Injection from a facelet for an ActionListener needs to be supported?
>>>
>>>
>>> Regards,
>>>
>>> Eduardo M. Breijo-Baullosa
>>>
>>
>>
>

[jira] [Comment Edited] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

2017-08-15 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127498#comment-16127498
 ] 

Peter Stöckli edited comment on MYFACES-4133 at 8/15/17 5:37 PM:
-

[~tandraschko] I'm not sure if I understand your question correctly.
But you're right only the ViewState-ID is sent to the client, but it's 
serialized as a Java object.
So the abstract view from server to client is:
ViewState-ID (plain) -> Java serialized VS-ID -> encrypted and signed VS-ID

Now if the last part is disabled (via {{org.apache.myfaces.USE_ENCRYPTION}}), a 
malicious user can send back a serialized Java Object as a ViewState, which is 
deserialized before the server is able to recognize that it doesn't contain a 
valid ViewState-ID.


was (Author: stockli):
[~tandraschko] I'm not sure if I understand your question correctly.
But you're right only the ViewState-ID is sent to the client, but it's 
serialized as a Java object.
So the abstract view from server to client is:
ViewState-ID (plain) -> Java serialized VS-ID -> encrypted and signed VS-ID

Now if the last part is disabled (via {{org.apache.myfaces.USE_ENCRYPTION}}, a 
malicious user can send back a serialized Java Object as a ViewState, which is 
deserialized before the server is able to recognize that it doesn't contain a 
valid ViewState-ID.

> Don't deserialize the client provided ViewState if the state saving method is 
> server
> 
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

2017-08-15 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127498#comment-16127498
 ] 

Peter Stöckli edited comment on MYFACES-4133 at 8/15/17 5:36 PM:
-

[~tandraschko] I'm not sure if I understand your question correctly.
But you're right only the ViewState-ID is sent to the client, but it's 
serialized as a Java object.
So the abstract view from server to client is:
ViewState-ID (plain) -> Java serialized VS-ID -> encrypted and signed VS-ID

Now if the last part is disabled (via {{org.apache.myfaces.USE_ENCRYPTION}}, a 
malicious user can send back a serialized Java Object as a ViewState, which is 
deserialized before the server is able to recognize that it doesn't contain a 
valid ViewState-ID.


was (Author: stockli):
[~tandraschko] I'm not sure if I understand your question correctly.
But your right only the ViewState-ID is sent to the client, but it's serialized 
as a Java object.
So the abstract view from server to client is:
ViewState-ID (plain) -> Java serialized VS-ID -> encrypted and signed VS-ID

Now if the last part is disabled, a malicious user can send back a serialized 
Java Object as a ViewState, which is deserialized before the server is able to 
recognize that it doesn't contain a valid ViewState-ID.

> Don't deserialize the client provided ViewState if the state saving method is 
> server
> 
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

2017-08-15 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127498#comment-16127498
 ] 

Peter Stöckli commented on MYFACES-4133:


[~tandraschko] I'm not sure if I understand your question correctly.
But your right only the ViewState-ID is sent to the client, but it's serialized 
as a Java object.
So the abstract view from server to client is:
ViewState-ID (plain) -> Java serialized VS-ID -> encrypted and signed VS-ID

Now if the last part is disabled, a malicious user can send back a serialized 
Java Object as a ViewState, which is deserialized before the server is able to 
recognize that it doesn't contain a valid ViewState-ID.

> Don't deserialize the client provided ViewState if the state saving method is 
> server
> 
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

2017-08-15 Thread Thomas Andraschko (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127468#comment-16127468
 ] 

Thomas Andraschko commented on MYFACES-4133:


Did you debugged this?
AFAIR only a view-state-id is sent to the client but serialization still happen 
if org.apache.myfaces.SERIALIZE_STATE_IN_SESSION is set (default is true).

> Don't deserialize the client provided ViewState if the state saving method is 
> server
> 
>
> Key: MYFACES-4133
> URL: https://issues.apache.org/jira/browse/MYFACES-4133
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 2.2.12
>Reporter: Peter Stöckli
>
> Currently the ViewState provided by the user is deserialized via Java 
> deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
> {{server}} (the default).
> The deserialization in this case is unecessary and most likely even slower 
> than just sending the ViewState Id directly.
> If a developer now disables the ViewState encryption by setting 
> {{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
> security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
> might have unintentionally introduced a dangerous remote code execution (RCE) 
> vulnerability as described 
> [here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].
> This has been discussed before on [Issue 
> MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Migrate all MyFaces projects to Git

2017-08-15 Thread Bernd Bohmann

issue created

https://issues.apache.org/jira/browse/INFRA-14883

Regards

Bernd

On Thu, Aug 10, 2017 at 9:45 PM, Dennis Kieselhorst  wrote:

> Lazy consensus is fine, please go ahead and file an infra issue. It will
> take some time anyway.
>

[jira] [Created] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

2017-08-15 Thread JIRA

Peter Stöckli created MYFACES-4133:
--

 Summary: Don't deserialize the client provided ViewState if the 
state saving method is server
 Key: MYFACES-4133
 URL: https://issues.apache.org/jira/browse/MYFACES-4133
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.12
Reporter: Peter Stöckli


Currently the ViewState provided by the user is deserialized via Java 
deserialization even when the {{javax.faces.STATE_SAVING_METHOD}} is set to 
{{server}} (the default).

The deserialization in this case is unecessary and most likely even slower than 
just sending the ViewState Id directly.
If a developer now disables the ViewState encryption by setting 
{{org.apache.myfaces.USE_ENCRYPTION}} to {{false}} (against the [MyFaces 
security advice|https://wiki.apache.org/myfaces/Secure_Your_Application]) he 
might have unintentionally introduced a dangerous remote code execution (RCE) 
vulnerability as described 
[here|https://www.alphabot.com/security/blog/2017/java/Misconfigured-JSF-ViewStates-can-lead-to-severe-RCE-vulnerabilities.html].

This has been discussed before on [Issue 
MYFACES-4021|https://issues.apache.org/jira/browse/MYFACES-4021].






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (TOBAGO-1779) Servlet authentication

2017-08-15 Thread Udo Schnurpfeil (JIRA)


[ 
https://issues.apache.org/jira/browse/TOBAGO-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127379#comment-16127379
 ] 

Udo Schnurpfeil commented on TOBAGO-1779:
-

Hi,

with Servlet 3.0 this "repair" is no longer needed. Please see the example 
login.xhtml in the "demo", not in the "addressbook".

If you really want to use the old way. Use

[jira] [Created] (TOBAGO-1779) Servlet authentication

2017-08-15 Thread Guido Dubois (JIRA)

Guido Dubois created TOBAGO-1779:


 Summary: Servlet authentication
 Key: TOBAGO-1779
 URL: https://issues.apache.org/jira/browse/TOBAGO-1779
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 4.0.0
Reporter: Guido Dubois


I want to use FORM Authentication, but it doesn't work.

I manipulate the login form according to the addressbook example.
**
 * This code is needed to "repair" the submit parameter names and url to use
 * the names that a required for servlet authentication.
 */
  function() {
jQuery(Tobago.Utils.escapeClientId('page:j_username::field')).attr('name', 
'j_username');
jQuery(Tobago.Utils.escapeClientId('page:j_password::field')).attr('name', 
'j_password');
jQuery(Tobago.Utils.escapeClientId('page::form')).attr('action', 
jQuery('[data-tobago-context-path]').data('tobago-context-path') + 
'/j_security_check');
  },


I have to change the searched field IDs. The field names are correctly setted. 
The action right to. On error there is not displayed the configured error-page. 
 and  are no more inserted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

2017-08-15 Thread Thomas Andraschko (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16127001#comment-16127001
 ] 

Thomas Andraschko commented on MYFACES-3844:


[~lu4242] WDYT about this one? I would apply it in 2.3 as it makes sense.

> move StartupServletContextListener config to web-fragment.xml
> -
>
> Key: MYFACES-3844
> URL: https://issues.apache.org/jira/browse/MYFACES-3844
> Project: MyFaces Core
>  Issue Type: Improvement
>  Components: JSR-344
>Affects Versions: 2.2.0
>Reporter: Gerhard Petracek
>Assignee: Leonardo Uribe
> Attachments: MYFACES-3844.patch
>
>
> users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
> listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Tobago 3.0.5

Re: [VOTE] Release Tobago 3.0.5

Re: Issue with injection in ActionListener JSF Artifact

[jira] [Comment Edited] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

[jira] [Comment Edited] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

[jira] [Commented] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

[jira] [Commented] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

Re: Migrate all MyFaces projects to Git

[jira] [Created] (MYFACES-4133) Don't deserialize the client provided ViewState if the state saving method is server

[jira] [Commented] (TOBAGO-1779) Servlet authentication

[jira] [Created] (TOBAGO-1779) Servlet authentication

[jira] [Commented] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

12 matches

Site Navigation

Mail list logo

Footer information