March 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-156) Create Deriver for Switchyard content (switchyard.xml)

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-156?page=com.atlassian.jira.plugin.... ] Work on SRAMP-156 started by Eric Wittmann. > Create Deriver for Switchyard content (switchyard.xml) > ------------------------------------------------------ > > Key: SRAMP-156 > URL: https://issues.jboss.org/browse/SRAMP-156 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.2.0 - Milestone 4 > > > Based on examples to be provided by Keith Babo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-161) Simplify db configuration

by Gary Brown (JIRA)

Gary Brown created RTGOV-161: -------------------------------- Summary: Simplify db configuration Key: RTGOV-161 URL: https://issues.jboss.org/browse/RTGOV-161 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Jeff Yu Fix For: 1.0.0.M5 In the M4 release, there were two persistence-unit definitions, one for a JTA datasource and one for a non-JTA datasource. All details are the same for both, the only difference is whether the datasource is JTA. This was necessary, because using H2 out of the box (for simple initial usage), only supports non-JTA. Specification of which entity manager (i.e. persistence unit) to use is defined in the overlord-rtgov.properties file. Ideally there should just be a single persistence-unit, and the data source (whether JTA or not) should be defined in a single place (i.e. overlord-rtgov.properties). However when the datasource info is moved to the properties file, it causes a problem as hibernate is being used to populate the schema for the H2 db. This appears to be causing hibernate to create its own entity manager, which does not take into account the properties in the overlord-rtgov.properties file. However that is the file where the "hibernate.hbm2ddl.auto=create-drop" property is defined??? If it is possible to remove datasource from persistence.xml, then it may also be good to package the persistence.xml in the activity-store-jpa module? rather than when building the overlord-rtgov.war. Main reason this has become an issue is that there is now a JPA based event processor, where the user can specify the entity manager, and persist received events. However when using the H2 db, it again becomes necessary to define a second persistent unit for the non-JTA datasource, and change the entity manager (i.e. persistence unit name) depending upon the db used in the event processor's configuration. So would like to simplify the whole approach so that persistence-unit only lists the classes, and the datasource, dialect, etc are all defined in one place (preferrably the overlord-rtgov.properties file), so that when switching between H2 and JTA dbs, the details only have to be changed in the one place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-179) Remove our version of the RESTEasy test classes

by Kurt Stam (JIRA)

Kurt Stam created SRAMP-179: ------------------------------- Summary: Remove our version of the RESTEasy test classes Key: SRAMP-179 URL: https://issues.jboss.org/browse/SRAMP-179 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kurt Stam Assignee: Kurt Stam RESTEasy 2.3.5 does not support setting the hostname in the test classes: https://issues.jboss.org/browse/RESTEASY-845 Four classes where copied from RESTEasy and support for setting the hostname was added: https://github.com/KurtStam/s-ramp/tree/master/s-ramp-common/src/test/jav... This was also submitted as a patch to RESTEasy. Once this patch is accepted, and we use this release, our version of these classes should be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-156) XSLT transformer for transforming information content

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-156?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-156. ------------------------------ Resolution: Done > XSLT transformer for transforming information content > ----------------------------------------------------- > > Key: RTGOV-156 > URL: https://issues.jboss.org/browse/RTGOV-156 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.0.0.M5 > > > Provide an xslt implementation of the org.overlord.rtgov.activity.processor.InformationTransformer interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-178) Trusting MIME type sent from clients is dangerous

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-178?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-178: ------------------------------------- I would classify the status of our existing mime-type handling as "straw man". It certainly isn't complete, and I definitely think we need to do better. > Trusting MIME type sent from clients is dangerous > ------------------------------------------------- > > Key: SRAMP-178 > URL: https://issues.jboss.org/browse/SRAMP-178 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Client > Affects Versions: 0.1.1 > Reporter: Lukas Krejci > Assignee: Kurt Stam > Fix For: 0.2.0 - Milestone 4 > > > While uploading artifact to the repository, the S-RAMP server completely trusts the client with the supplied mime type and uses it from thereafter. > This also includes the time when the artifact is downloaded from S-RAMP server. > This is quite dangerous, IMHO, because it gives the potential attackers the means for making certain types of files look like something they aren't. This could be a nice vector to exploiting vulnerabilities in applications that then open such files. > For example, consider this command: > curl -H 'Content-Type: image/png' -H 'Slug: wha.pkg' --data-binary @tmp.pdf 'http://localhost:8080/s-ramp-server/s-ramp/core/Document' > This will create an artifact called "wha.pkg" in the repository, which will have the stored content type of "image/png" but the actual data will be a PDF. > IMHO, the mime type detection should be purely a server-side affair ignoring any hints of mimetype sent in by the clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-178) Trusting MIME type sent from clients is dangerous

by Kurt Stam (JIRA)

[ https://issues.jboss.org/browse/SRAMP-178?page=com.atlassian.jira.plugin.... ] Kurt Stam updated SRAMP-178: ---------------------------- Fix Version/s: 0.2.0 - Milestone 4 > Trusting MIME type sent from clients is dangerous > ------------------------------------------------- > > Key: SRAMP-178 > URL: https://issues.jboss.org/browse/SRAMP-178 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Client > Affects Versions: 0.1.1 > Reporter: Lukas Krejci > Assignee: Kurt Stam > Fix For: 0.2.0 - Milestone 4 > > > While uploading artifact to the repository, the S-RAMP server completely trusts the client with the supplied mime type and uses it from thereafter. > This also includes the time when the artifact is downloaded from S-RAMP server. > This is quite dangerous, IMHO, because it gives the potential attackers the means for making certain types of files look like something they aren't. This could be a nice vector to exploiting vulnerabilities in applications that then open such files. > For example, consider this command: > curl -H 'Content-Type: image/png' -H 'Slug: wha.pkg' --data-binary @tmp.pdf 'http://localhost:8080/s-ramp-server/s-ramp/core/Document' > This will create an artifact called "wha.pkg" in the repository, which will have the stored content type of "image/png" but the actual data will be a PDF. > IMHO, the mime type detection should be purely a server-side affair ignoring any hints of mimetype sent in by the clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-178) Trusting MIME type sent from clients is dangerous

by Kurt Stam (JIRA)

[ https://issues.jboss.org/browse/SRAMP-178?page=com.atlassian.jira.plugin.... ] Kurt Stam commented on SRAMP-178: --------------------------------- This lines up complete with the specification: "A string indicating the MIME Media type of the content. This is set by the server as part of processing the publication of the document, and cannot be changed by the user." I think at the moment we derive the mimeType from the REST endpoint, but I think we should only do this as tie breaker in case our mime handler comes back with more then one option. > Trusting MIME type sent from clients is dangerous > ------------------------------------------------- > > Key: SRAMP-178 > URL: https://issues.jboss.org/browse/SRAMP-178 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Client > Affects Versions: 0.1.1 > Reporter: Lukas Krejci > Assignee: Kurt Stam > > While uploading artifact to the repository, the S-RAMP server completely trusts the client with the supplied mime type and uses it from thereafter. > This also includes the time when the artifact is downloaded from S-RAMP server. > This is quite dangerous, IMHO, because it gives the potential attackers the means for making certain types of files look like something they aren't. This could be a nice vector to exploiting vulnerabilities in applications that then open such files. > For example, consider this command: > curl -H 'Content-Type: image/png' -H 'Slug: wha.pkg' --data-binary @tmp.pdf 'http://localhost:8080/s-ramp-server/s-ramp/core/Document' > This will create an artifact called "wha.pkg" in the repository, which will have the stored content type of "image/png" but the actual data will be a PDF. > IMHO, the mime type detection should be purely a server-side affair ignoring any hints of mimetype sent in by the clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-178) Trusting MIME type sent from clients is dangerous

by Lukas Krejci (JIRA)

Lukas Krejci created SRAMP-178: ---------------------------------- Summary: Trusting MIME type sent from clients is dangerous Key: SRAMP-178 URL: https://issues.jboss.org/browse/SRAMP-178 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Client Affects Versions: 0.1.1 Reporter: Lukas Krejci Assignee: Kurt Stam While uploading artifact to the repository, the S-RAMP server completely trusts the client with the supplied mime type and uses it from thereafter. This also includes the time when the artifact is downloaded from S-RAMP server. This is quite dangerous, IMHO, because it gives the potential attackers the means for making certain types of files look like something they aren't. This could be a nice vector to exploiting vulnerabilities in applications that then open such files. For example, consider this command: curl -H 'Content-Type: image/png' -H 'Slug: wha.pkg' --data-binary @tmp.pdf 'http://localhost:8080/s-ramp-server/s-ramp/core/Document' This will create an artifact called "wha.pkg" in the repository, which will have the stored content type of "image/png" but the actual data will be a PDF. IMHO, the mime type detection should be purely a server-side affair ignoring any hints of mimetype sent in by the clients. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-177) Enable authentication for HEAD requests in s-ramp-server

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-177: ----------------------------------- Summary: Enable authentication for HEAD requests in s-ramp-server Key: SRAMP-177 URL: https://issues.jboss.org/browse/SRAMP-177 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.3.0 - Future (Unscheduled) Currently HEAD requests are allowed even without authentication information (basic auth). This was done because jBPM requires it. I have added the following issue: https://issues.jboss.org/browse/JBPM-3967 Once it is fixed, we can fix this issue by updating the s-ramp-server web.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-149) mvn clean doesn't work in samle folder (deployment)

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-149?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-149. ------------------------------ Resolution: Done > mvn clean doesn't work in samle folder (deployment) > --------------------------------------------------- > > Key: RTGOV-149 > URL: https://issues.jboss.org/browse/RTGOV-149 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Jeff Yu > Assignee: Gary Brown > Fix For: 1.0.0.M5 > > > mvn clean won't remove the sample's artifact from the switchyard. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues March 2013