You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(85) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(47) |
Feb
(127) |
Mar
(268) |
Apr
(78) |
May
(47) |
Jun
(38) |
Jul
(131) |
Aug
(221) |
Sep
(187) |
Oct
(54) |
Nov
(111) |
Dec
(84) |
2011 |
Jan
(152) |
Feb
(106) |
Mar
(94) |
Apr
(90) |
May
(53) |
Jun
(20) |
Jul
(24) |
Aug
(37) |
Sep
(32) |
Oct
(70) |
Nov
(22) |
Dec
(15) |
2012 |
Jan
(33) |
Feb
(110) |
Mar
(24) |
Apr
(1) |
May
(11) |
Jun
(8) |
Jul
(12) |
Aug
(37) |
Sep
(39) |
Oct
(81) |
Nov
(38) |
Dec
(50) |
2013 |
Jan
(23) |
Feb
(53) |
Mar
(23) |
Apr
(5) |
May
(19) |
Jun
(16) |
Jul
(16) |
Aug
(9) |
Sep
(21) |
Oct
(1) |
Nov
(2) |
Dec
(8) |
2014 |
Jan
(16) |
Feb
(6) |
Mar
(27) |
Apr
(1) |
May
(10) |
Jun
(1) |
Jul
(4) |
Aug
(10) |
Sep
(19) |
Oct
(22) |
Nov
(4) |
Dec
(6) |
2015 |
Jan
(3) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(11) |
Jun
(23) |
Jul
(14) |
Aug
(10) |
Sep
(10) |
Oct
(9) |
Nov
(18) |
Dec
(4) |
2016 |
Jan
(5) |
Feb
(5) |
Mar
|
Apr
(2) |
May
(15) |
Jun
(2) |
Jul
(8) |
Aug
(2) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
(2) |
Feb
(12) |
Mar
(22) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(7) |
Oct
(19) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Evgeny G. <gaz...@gm...> - 2010-03-25 13:15:34
|
> That is too difficult to get this stable, too error prone. I thought of it..... > Anyway we must support pack200 compressed jars as well. For this we > need to unsign/normalize/sign/pack200/gzip eachof the jars. Trus > me..... that is too difficult on the fly. > Ok, put signed jars into different folder(s) (but not in DB)? And share this folder(s) via lib function. So we can have unsigned, signed and packed as pack200 jars -------- Evgeny |
From: Wolfgang M. <wol...@ex...> - 2010-03-25 13:03:26
|
Hi Dan, > Here is a link to a very early DRAFT of "A Beginners Guide to XRX". Great. I think the document explains things at the right level of complexity. Not too easy, not too difficult. Maybe it would be good if some of our rather non-technical users could go through the text and tells us where they have questions. > I have just used the default oXygen DocBook rendering and I am still playing > around with the image scaling and formatting. Any suggestions on DocBook > formatting or options would be appreciated. The stylesheet we use for the rest of the documentation is webapp/stylesheets/db2xhtml.xsl (or webapp/stylesheets/db2html.xsl). It automatically applies the standard eXist design and should cover most of the docbook tags. > My real questions are what are the critical "learning points" of getting new > people up and running using eXist and XRX to build simple CRUDS > applications? What are the learning barriers we need to get people over? I think the major problem is that eXist provides several ways to approach XRX development. The first question of a new user might be: where do I put my XQuery files? You answer this question by establishing a number of conventions. This is good. I think the text should indeed guide the user by presenting clear decisions. However, we may need to mention that there can be other approaches, e.g. if you are using eXist within your own web application besides other components. URL mapping and rewriting will be another important topic we may need to deal with. Once they have their basic application setup, their next question probably is how to map simpler URLs to the CRUD operations. > Will very simple templates and examples help? How can we combine our > DocBook versions with the WikiBooks? How can we move to a "topic-based" > system that will work with an overall search engine to help people quickly > find the example code they need to solve a specific tasks? Could we export the wikibook contents to XML and set up a search page within eXist which can directly query for topics, titles, examples and the like? Wolfgang |
From: Dannes W. <da...@ex...> - 2010-03-25 12:51:40
|
Hi, On Thu, Mar 25, 2010 at 1:25 PM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Storing jars in db is not good way, what about signing jars > on the fly and cache then? That is too difficult to get this stable, too error prone. I thought of it..... Anyway we must support pack200 compressed jars as well. For this we need to unsign/normalize/sign/pack200/gzip eachof the jars. Trus me..... that is too difficult on the fly. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-03-25 12:26:01
|
Storing jars in db is not good way, what about signing jars on the fly and cache then? ------------ Evgeny |
From: Dannes W. <da...@ex...> - 2010-03-25 11:58:58
|
On Thu, Mar 25, 2010 at 11:31 AM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Simple add path EXIST_HOME/lib/private and put here the your private jars if you have one. Sure you are right, but that is an implicit result of the changes. Until now my jars were not exposed. On Thu, Mar 25, 2010 at 11:39 AM, Evgeny Gazdovsky <gaz...@gm...> wrote: > Old JNLP stuf have one hardcoded jnlp sorry I refuse to say OLD jnlp code. IMO is the current and primary interface, still. :-) > and can give access to any core exist's jar. But they do not right now...... hardcoded. If we want to expose exist-db internal stuff (e.g. jars) it must be discussed, because of the implicationsm, which are sometimes not directly visible. > We need only some basic servlets like REST or XQueryServlet. Maybe you are right. Maybe not. We decided to design it this way some time ago, probably for good reasons. Any changes must be discussed and agreed on. Realize that the way some parts are coded (direct in servlets) is the most efficient way of IO to the outside world. As I think more of it, probably we should not expose exist-db internal jars. E.g. (1) with all kind of signing issues which will appear (just as you saw yesterday with fluent.jar). Maybe we should store these jars in the database and have these exposed. With this, it is more easy to install and upgrade your java based application (with the coming generic packaging mechanisms) (2) I fear of the maintenance penalties we'll get. I do not wanna test all your apps if i decide to upgrade jars files (or add them to the core) D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:39:50
|
> The differences that I see is xquery way to access information. eXist > information page (xml file) can have the list of jars that are used. > > If old webstart have all this, can we rewrite xquery functions to use it > as backend? > Old JNLP stuf have one hardcoded jnlp and can give access to any core exist's jar. Think that we must move some eXist's functionality like webdav, atom, xmlrpc from servlet layer to xquery webapp. It will be more flexible. And developers could change functionality of this webapp in they's application. So possible add virtual collections for webdav. We need only some basic servlets like REST or XQueryServlet. ---------- Evgeny |
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:31:52
|
Simple add path EXIST_HOME/lib/private and put here the your private jars if you have one. ---------- Evgeny |
From: Evgeny G. <gaz...@gm...> - 2010-03-25 10:13:54
|
Why? Just in JnlpServlet you can get some exist's jar too. all core/optional jars from third part. Idea is give access to guest, otherwise possible to use file module ---------- Evgeny |
From: Dan M. <dan...@gm...> - 2010-03-25 01:04:48
|
Here is a link to a very early DRAFT of "A Beginners Guide to XRX". http://www.syntactica.com/training/xrx/beginners/index.html You will find links to: - the HTML and PDF versions of the beginner's guide - the DocBook source - a zip file of the source code - a link to a the demo CRUDS app running on the Syntactica web server I have just used the default oXygen DocBook rendering and I am still playing around with the image scaling and formatting. Any suggestions on DocBook formatting or options would be appreciated. My real questions are what are the critical "learning points" of getting new people up and running using eXist and XRX to build simple CRUDS applications? What are the learning barriers we need to get people over? Will very simple templates and examples help? How can we combine our DocBook versions with the WikiBooks? How can we move to a "topic-based" system that will work with an overall search engine to help people quickly find the example code they need to solve a specific tasks? Thanks! - Dan |
From: James F. <jam...@ex...> - 2010-03-24 22:23:36
|
On 24 March 2010 22:59, Loren Cahlander <lor...@gm...> wrote: > I agree that a monthly conference call would be a good thing. We should > try to agree on a week of the month and day of week, like the 2nd Sunday of > the month. We would have to come up with a time of day that we all can > reasonably attend. > a few observations: a) in my experience they phone conferences can quickly become unsustainable, sorry to sound negative but what will happen is 1-2 teleconferences then chaotic oscillator effect with sum energy being used to organise greater then sum useful output ... the video broadcast ,means its 'opt in' by interested individuals, ensures that the individual broadcasting is prepared and there is just enough comms via IRC ... though I maybe wrong about all this ;) b) 'many to many' conversations over the fone can be just as tedious as long email threads, I would rather optimize a 'broadcast' and enable with background channel via irc ... though I am not against phone conferences but lets schedule them one at a time. So that being said, when would be good for the 'next' fone conference c) we could organize 'points on the horizons' for future face to faces as far in advance as possible ... so that being said, whens the next one ? so 3 easy questions: 1) When is a good time for a fone conference for everyone ? 2) When is likely face to face to happen and what continent ? 3) I am going ahead with experiment ... I will be asking Evgeny to broadcast with me and we will release time for this (sometime in the coming week or so) ... I will give an overview on 'XProc development in eXist' and maybe 'Unit Testing XQuery overview'. thx J |
From: Loren C. <lor...@gm...> - 2010-03-24 21:59:13
|
I agree that a monthly conference call would be a good thing. We should try to agree on a week of the month and day of week, like the 2nd Sunday of the month. We would have to come up with a time of day that we all can reasonably attend. On Mar 24, 2010, at 03:50 PM, Dmitriy Shabanov wrote: > I do understand that it quite difficult to have all at F2F meeting. May > be, we should organize calls to discuss problems. It will mean that > eXist open not by mail-lists, but by talks too. (not often, ones a month > or around) > > On Wed, 2010-03-24 at 21:41 +0100, James Fuller wrote: >> Hello All, >> >> >> This has been an interesting thread and reminded me a few things. >> >> >> Basically Open Source development, by its nature, is highly >> distributed and one of the challenges to work on is communication ... >> this is why so much good work happens at face to face meetings because >> there really is no substitute for talking and being with people in >> real time. Also I note there are lots of people using English as 2nd >> language which can be doubly difficult over email/chat. >> >> >> Email and chat hit limitations quickly and also asks a lot of energy >> from both sender and receiver to parse and understand. >> >> >> So we are proposing a new experiment ... nothing too ground breaking >> but should be easy to setup as well as go as quickly as possible to >> understanding Evgeny cool stuff and address Dannes concerns all at the >> same time. >> >> >> So the big (not in capitals) idea is ......... >> >> >> If Evgeny has a laptop with a webcam then I can set him up to do a >> video broadcast ... so he can in realtime explain the work done ... >> whilst he is broadcasting we can all be on IRC and I can act as >> moderator of the broadcast. >> >> >> Its easy for me to setup (as I just did it again for XML Prague) and >> works really well ... and is superior to skype as it gives Evgeny a >> forum to speak without too may people interrupting. >> >> >> So ... Evgeny are you up for it ? If so go onto irc to existdb and we >> can work out the technical details together then we can announce >> time/date for this 'performance' ! >> >> >> James Fuller >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ Exist-development mailing list Exi...@li... https://lists.sourceforge.net/lists/listinfo/exist-development > -- > Cheers, > > Dmitriy Shabanov > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev_______________________________________________ > Exist-development mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-development |
From: Dmitriy S. <sha...@gm...> - 2010-03-24 20:52:16
|
I do understand that it quite difficult to have all at F2F meeting. May be, we should organize calls to discuss problems. It will mean that eXist open not by mail-lists, but by talks too. (not often, ones a month or around) On Wed, 2010-03-24 at 21:41 +0100, James Fuller wrote: > Hello All, > > > This has been an interesting thread and reminded me a few things. > > > Basically Open Source development, by its nature, is highly > distributed and one of the challenges to work on is communication ... > this is why so much good work happens at face to face meetings because > there really is no substitute for talking and being with people in > real time. Also I note there are lots of people using English as 2nd > language which can be doubly difficult over email/chat. > > > Email and chat hit limitations quickly and also asks a lot of energy > from both sender and receiver to parse and understand. > > > So we are proposing a new experiment ... nothing too ground breaking > but should be easy to setup as well as go as quickly as possible to > understanding Evgeny cool stuff and address Dannes concerns all at the > same time. > > > So the big (not in capitals) idea is ......... > > > If Evgeny has a laptop with a webcam then I can set him up to do a > video broadcast ... so he can in realtime explain the work done ... > whilst he is broadcasting we can all be on IRC and I can act as > moderator of the broadcast. > > > Its easy for me to setup (as I just did it again for XML Prague) and > works really well ... and is superior to skype as it gives Evgeny a > forum to speak without too may people interrupting. > > > So ... Evgeny are you up for it ? If so go onto irc to existdb and we > can work out the technical details together then we can announce > time/date for this 'performance' ! > > > James Fuller > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ Exist-development mailing list Exi...@li... https://lists.sourceforge.net/lists/listinfo/exist-development -- Cheers, Dmitriy Shabanov |
From: James F. <jam...@ex...> - 2010-03-24 20:41:59
|
Hello All, This has been an interesting thread and reminded me a few things. Basically Open Source development, by its nature, is highly distributed and one of the challenges to work on is communication ... this is why so much good work happens at face to face meetings because there really is no substitute for talking and being with people in real time. Also I note there are lots of people using English as 2nd language which can be doubly difficult over email/chat. Email and chat hit limitations quickly and also asks a lot of energy from both sender and receiver to parse and understand. So we are proposing a new experiment ... nothing too ground breaking but should be easy to setup as well as go as quickly as possible to understanding Evgeny cool stuff and address Dannes concerns all at the same time. So the big (not in capitals) idea is ......... If Evgeny has a laptop with a webcam then I can set him up to do a video broadcast ... so he can in realtime explain the work done ... whilst he is broadcasting we can all be on IRC and I can act as moderator of the broadcast. Its easy for me to setup (as I just did it again for XML Prague) and works really well ... and is superior to skype as it gives Evgeny a forum to speak without too may people interrupting. So ... Evgeny are you up for it ? If so go onto irc to existdb and we can work out the technical details together then we can announce time/date for this 'performance' ! James Fuller |
From: Dannes W. <da...@ex...> - 2010-03-24 20:24:50
|
HI, On 24 Mar 2010, at 20:34 , Wolfgang Meier wrote: > I do like the gate features Evgeny added and I value his bug fixes and improvements to the trigger code. Don't get me wrong on this :-) I highly appreciate *any* help and contribution to the eXist-db codebase, no exclusions here! Kind regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Wolfgang M. <wol...@ex...> - 2010-03-24 20:03:34
|
Hi guys, Adam is currently writing a draft for a general eXist-db Developers Manifesto, which will be available for your reading and discussion within the next days. In the meantime, I'd like to ask every contributor to adhere to some basic rules: * new features should be announced and discussed on exist-development *before* they are committed. In particular, you should try to explain why the feature will be beneficial to the project as a whole. I think we are a very open community, so nobody has to fear that he will be outright rejected. We may just have some suggestions. * new code must always be accompanied by test cases. Integration tests can be written in XQuery. * you must run the test suite(s) before committing. Changes to anything XQuery-related require the XQTS to be run. After major changes, make sure all the demo applications which ship with eXist are still working as before. * we want all commits to be checked by as many people as possible. It is thus important that related commits are kept together where possible. For example, I made only 2 commits to trunk during the past 2 days, while Evgeny did 13! This inflation of commits makes it difficult to detect problems. Please limit your changes to the necessary minimum. Don't touch code unless you really have to modify it. The less classes are changed, the easier it is for other people to understand the purpose of the commit. If you want to cleanup something, do it in a separate commit and mark it as "cleaning up". Wolfgang |
From: Wolfgang M. <wol...@ex...> - 2010-03-24 19:34:44
|
Dannes, you probably invested more time than anyone else into the maintenance of eXist and the quality of our builds. Your opinion thus weighs heavily. > I said no but the code ended up > in trunk anyway. I feel quite bad on this. I do like the gate features Evgeny added and I value his bug fixes and improvements to the trigger code. However, it should be obvious that access to SVN trunk has to be controlled. A "no" from Dannes, if it has been definite, cannot be simply ignored. It can be discussed, sure, and I know he's willing to listen to good arguments. But just committing is not the way to go. So please Evgeny, make a suggestion on how to resolve this issue. Wolfgang |
From: James F. <jam...@gm...> - 2010-03-24 19:30:24
|
On Wed, Mar 24, 2010 at 8:11 PM, Dmitriy Shabanov <sha...@gm...> wrote: > On Wed, 2010-03-24 at 20:03 +0100, James Fuller wrote: >> Dont forget, its easy to add xquery level unit tests now as well aka >> eXist/test/src/xquery > > I do not believe to unit tests as you do :-) > (especially in security area) testing (of all types) is one of the few techniques one can employ to achieve good security characteristics in software ... but if you have any other new techniques on the matter, I would love to hear ... I know the answer isn't 'write perfect code' because I have been trying that for 25 years with little success. I don't believe in unit tests as some magic bullet, but at a minimum they do a good job at explaining assumptions a few months/years from now (e.g. those hard coded paths). otherwise, back to the thread ... Dannes needs to be satisfied that all is well with this stuff and as I understand it he isn't because he raised a list of concerns which have yet to be addressed. J |
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:21:41
|
On Wed, 2010-03-24 at 20:12 +0100, Dannes Wessels wrote: > Hi, > > On Wed, Mar 24, 2010 at 8:05 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > > > My proposal is to use > > ./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar > > instead ./lib/user) > > > > hardcode to jars mask, not folders. > > With this, the functionality will loose the flexibility gev intended > to have. See my last mail, think of the maintaince issues we (read: I) > will have if we decide to add new jar files. > > To be more clear: the functionality you describe we basically already > have in trunk since years: the webstart interfaces. This interface is > well tested, reliable, stable, secure and maintained. Lot's of effort > is put in this code, from the beginning of the addition I see the > addition as a doubloure we already had. The differences that I see is xquery way to access information. eXist information page (xml file) can have the list of jars that are used. If old webstart have all this, can we rewrite xquery functions to use it as backend? -- Cheers, Dmitriy Shabanov PS I do understand all problems, but it should not block ideas :-) |
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:13:33
|
On Wed, 2010-03-24 at 20:03 +0100, James Fuller wrote: > Dont forget, its easy to add xquery level unit tests now as well aka > eXist/test/src/xquery I do not believe to unit tests as you do :-) (especially in security area) -- Cheers, Dmitriy Shabanov |
From: Dannes W. <da...@ex...> - 2010-03-24 19:12:58
|
Hi, On Wed, Mar 24, 2010 at 8:05 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > My proposal is to use > ./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar > instead ./lib/user) > > hardcode to jars mask, not folders. With this, the functionality will loose the flexibility gev intended to have. See my last mail, think of the maintaince issues we (read: I) will have if we decide to add new jar files. To be more clear: the functionality you describe we basically already have in trunk since years: the webstart interfaces. This interface is well tested, reliable, stable, secure and maintained. Lot's of effort is put in this code, from the beginning of the addition I see the addition as a doubloure we already had. regards Dannes -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dannes W. <da...@ex...> - 2010-03-24 19:08:35
|
All, I have been discussing this feature for a long time with Evgeny. For a number of reasons I feel really uncomfortable with the new code. On one side the provided functionality, on the other hand, the way the jars ended up into trunk. To start with the latter: it was added to trunk without agreement of the exist-db core team. I had discussions per mail and chat with Evgeny, but these were not successful. I said no but the code ended up in trunk anyway. I feel quite bad on this. About the functionality, my concerns were, and still are: - security (see recent discussions, there is no limit what to download, even private jars); no dbadmin control - double functionality: we have a Webstart interface which provides access to ALL jar files you require to connect with exist-db. Oxygen does not use this interface, but they know of it, since I talked about that. - lack of use case. for weeks I didn't see the added value. A understandable usecase had been missing since the beginning. - lack of testcases other concerns - then original webstart interface was intentionally killed (but denied); fixed in the end after hard discussions - the code was not documented, no comments, no javadoc (being improved) - the name is strange. I still do not agree on "Lib"nothing name. - maintainability. I do not want to check all interfaces and clients if *I* decide to upgrade a jar file, or if we need a new 3rd party jar file. it is hard enough already. We need to consider this seriously Sure things got improved last week, but I still am not convinced about it. I probably *could* live with serving out jar files that are stored in the database. This solves all security issues as well. And the maintenance issue. SO after all, I am still against this addition D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dmitriy S. <sha...@gm...> - 2010-03-24 19:07:43
|
On Wed, 2010-03-24 at 19:56 +0100, Dannes Wessels wrote: > Hi, > > On Wed, Mar 24, 2010 at 7:53 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > ok, for now it hard-coded to > > > > private final static String LIB_WEBINF = "WEB-INF/lib/"; > > private final static String[] LIB = {"./lib/core", > > "./lib/optional", "./lib/extensions", "./lib/user", "."}; > > > > so, simples solution hardcode it jars mask like log4j-%latest%.jar too > > (src/org/exist/start/start.config can be used/reused) > > > > Will it solve this problem? > > No. I put my personal jars in lib/user, these should NEVER be exposed. > furthermore the classpath is not complete. How is it possible if it in not in masks list? My proposal is to use ./lib/core/log4j-%latest%.jar instead ./lib/core (or ./lib/user/fop.jar instead ./lib/user) hardcode to jars mask, not folders. -- Cheers, Dmitriy Shabanov |
From: James F. <jam...@gm...> - 2010-03-24 19:03:35
|
On Wed, Mar 24, 2010 at 7:53 PM, Dmitriy Shabanov <sha...@gm...> wrote: > Hey, > > On Wed, 2010-03-24 at 19:46 +0100, Dannes Wessels wrote: >> On Wed, Mar 24, 2010 at 7:23 PM, Dmitriy Shabanov <sha...@gm...> wrote: >> > Do we speak about LibFunction? I don't see any security issue there, or >> > I'm missing something? >> >> > Any scenario? >> >> The issue is fundamentally. A jar library is specified by a query, >> that can live anywhere, even oustide the db. Basically all jar files >> can be specified, >> including those who you might not want to expose, e.g. private >> libraries. > > ok, for now it hard-coded to > > private final static String LIB_WEBINF = "WEB-INF/lib/"; > private final static String[] LIB = {"./lib/core", > "./lib/optional", "./lib/extensions", "./lib/user", "."}; > > so, simples solution hardcode it jars mask like log4j-%latest%.jar too > (src/org/exist/start/start.config can be used/reused) > > Will it solve this problem? I would also like to have unit test(s) that asserts that it is not a problem ... though admittedly there are other code 'hotspots' (including code I am writing) where we need to test with respect to security, this is probably as good a place to start as anywhere else. Dont forget, its easy to add xquery level unit tests now as well aka eXist/test/src/xquery J |
From: Dannes W. <da...@ex...> - 2010-03-24 18:57:09
|
Hi, On Wed, Mar 24, 2010 at 7:53 PM, Dmitriy Shabanov <sha...@gm...> wrote: > ok, for now it hard-coded to > > private final static String LIB_WEBINF = "WEB-INF/lib/"; > private final static String[] LIB = {"./lib/core", > "./lib/optional", "./lib/extensions", "./lib/user", "."}; > > so, simples solution hardcode it jars mask like log4j-%latest%.jar too > (src/org/exist/start/start.config can be used/reused) > > Will it solve this problem? No. I put my personal jars in lib/user, these should NEVER be exposed. furthermore the classpath is not complete. D. -- eXist-db Native XML Database - http://exist-db.org Join us on linked-in: http://www.linkedin.com/groups?gid=35624 |
From: Dmitriy S. <sha...@gm...> - 2010-03-24 18:55:19
|
Hey, On Wed, 2010-03-24 at 19:46 +0100, Dannes Wessels wrote: > On Wed, Mar 24, 2010 at 7:23 PM, Dmitriy Shabanov <sha...@gm...> wrote: > > Do we speak about LibFunction? I don't see any security issue there, or > > I'm missing something? > > > Any scenario? > > The issue is fundamentally. A jar library is specified by a query, > that can live anywhere, even oustide the db. Basically all jar files > can be specified, > including those who you might not want to expose, e.g. private > libraries. ok, for now it hard-coded to private final static String LIB_WEBINF = "WEB-INF/lib/"; private final static String[] LIB = {"./lib/core", "./lib/optional", "./lib/extensions", "./lib/user", "."}; so, simples solution hardcode it jars mask like log4j-%latest%.jar too (src/org/exist/start/start.config can be used/reused) Will it solve this problem? -- Cheers, Dmitriy Shabanov |