exist-development

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[<fi...@us...>]

To be more precise:

The code for eXist-db is still released under the LGPL. If code that Adam 
included is available under the GPL, that doesn't change the license of the 
eXist-db code; it just means the /combination/ of the two has to be released 
under the GPL.

Luigi

On Sunday, 05 February 2012, Alain Couthures wrote:
> That's the official FAQ:
> 
> 
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLInProprietarySystem
> 
> Le 05/02/2012 22:12, Adam Retter a écrit :
> > Hi Alain,
> >
> > Thats interesting, can you tell me where you got that quote from
> > please? ...so that I can read some more!
> >
> > On 5 February 2012 21:11, Alain Couthures<ala...@ag...>  
wrote:
> >> Hello Adam,
> >>
> >> As far as I understand, including a GPL library in eXist-db would imply 
that
> >> eXist-db is becoming GPL itself!
> >>
> >> "A system incorporating a GPL-covered program is an extended version of 
that
> >> program. The GPL says that any extended version of the program must be
> >> released under the GPL if it is released at all."
> >>
> >> -Alain
> >>
> >> Le 05/02/2012 21:48, Adam Retter a écrit :
> >>
> >>> I really detest trying to understand open source licences. I have
> >>> placed something which is GPLv2 into eXist-db. eXist-db is LGPL 2.1.
> >>> It seems to me that from what I can Google and understand (not much),
> >>> that the licences are compatible.
> >>>
> >>> However, I have had some concerns raised that we should not use
> >>> anything which is GPLv2. As Linux itself is GPLv2 and many companies
> >>> use this, I am not sure I understand the issue.
> >>>
> >>> If anyone is concerned that I should not include GPLv2 libraries,
> >>> please tell me, but more importantly please tell me why its important.
> >>>
> >>> Thanks Adam.
> >>>
> >
> >
> 
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dmitriy S. <sha...@gm...>]

Suprised too....
RIPEMD made by open community, but SHA part of jvm....
06.02.2012 4:42 пользователь "Joe Wicentowski" <jo...@gm...> написал:

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

I chose RIPEMD-160 over SHA because SHA is a closed proprietary algorithm
developed by the NSA, whereas RIPEMD is an open algorithm developed under
public scrutiny. Apart from the hash strength of SHA, its impossible to
reason about its security characteristics.
On Feb 6, 2012 3:40 AM, "Dmitriy Shabanov" <sha...@gm...> wrote:

> Suprised too....
> RIPEMD made by open community, but SHA part of jvm....
> 06.02.2012 4:42 пользователь "Joe Wicentowski" <jo...@gm...> написал:
>

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

Hi Adam,

On Mon, Feb 6, 2012 at 11:12 AM, Adam Retter <ad...@ex...> wrote:

>  I chose RIPEMD-160 over SHA because SHA is a closed proprietary algorithm
> developed by the NSA, whereas RIPEMD is an open algorithm developed under
> public scrutiny. Apart from the hash strength of SHA, its impossible to
> reason about its security characteristics.
>
Thnx for the answer, but I don;t see your point. IMO SHA is the standard
way of doing these things and is proven technology and is used everywhere.
The choice of RIPEMD-160 looks to me as a "I don't trust the world'
argument?

In addition, another JAR file is added, I think we must be conservative
doing this (new maintenance thingy). Why another jar if the JVM provides
all we need?

cheers

Dannes

-- 
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Hungerburg <pc...@my...>]

Am 2012-02-06 11:12, schrieb Adam Retter:
> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
> algorithm developed by the NSA

Can one be more open than this: http://tools.ietf.org/html/rfc3174

OpenJDK also supports SHA-2, eg the 224 variant 
http://openjdk.java.net/jeps/130

-- 
peter

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

On Feb 6, 2012 10:25 AM, "Dannes Wessels" <da...@ex...> wrote:
>
> Hi Adam,
>
> On Mon, Feb 6, 2012 at 11:12 AM, Adam Retter <ad...@ex...> wrote:
>>
>> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
algorithm developed by the NSA, whereas RIPEMD is an open algorithm
developed under public scrutiny. Apart from the hash strength of SHA, its
impossible to reason about its security characteristics.
>
> Thnx for the answer, but I don;t see your point. IMO SHA is the standard
way of doing these things and is proven technology and is used everywhere.
The choice of RIPEMD-160 looks to me as a "I don't trust the world'
argument?

If I understand your eesponse, I think you see my point, but rather you
disagree with my opinion. That's fine.

> In addition, another JAR file is added, I think we must be conservative
doing this (new maintenance thingy). Why another jar if the JVM provides
all we need?
>

The JVM does not provide RIPEMD, hence the extra library

> cheers
>
> Dannes
>
> --
> eXist-db Native XML Database - http://exist-db.org
> Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

>> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
>> algorithm developed by the NSA
>
> Can one be more open than this: http://tools.ietf.org/html/rfc3174

If I understand correctly, is that not just the implementation of the
algorithm? SHA-1 has been proven several times to have weaknesses and
each time its proven the feasibility of the attack has significantly
increased. In fact the US Government now recommends that government
departments use SHA-2 or better and not SHA-1.

> OpenJDK also supports SHA-2, eg the 224 variant
> http://openjdk.java.net/jeps/130

Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160
bits. RIPEMD-160 should be faster (less computationally intensive)
than SHA-2 if I understand correctly, and in addition requires less
memory and storage for the digest. Like SHA-1, SHA-2 was also
developed in private in a proprietary way, unlike RIPEMD-160.

> --
> peter
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

Hi,  

On Monday, 6 February 2012 at 19:40 , Adam Retter wrote:  
> The JVM does not provide RIPEMD, hence the extra library  
I disagree using an obscure technology, which requires a strange additional jar file…..  

please can we reimplement this part of the further excellent and highly required change with a standard technology available in the JVM? How much work is it?

SHA-x : +1 for me

cheers

Dannes

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

> The JVM does not provide RIPEMD, hence the extra library
>
> I disagree using an obscure technology, which requires a strange additional
> jar file…..

But RIPEMD is not obscure! also a strange additional jar seems a bit
strong, its part of the GNU project.

> please can we reimplement this part of the further excellent and highly
> required change with a standard technology available in the JVM? How much
> work is it?
>
> SHA-x : +1 for me

SHA-x: -1 for me



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Leif-Jöran O. <lj...@ex...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, I agree with this. Though I must say someone med a very crappy
decision when chosing this very subjective and not really motivated
subject line. Could we move this to a clean thread?

Cheers,
Leif-Jöran

Den 2012-02-06 19:56, Adam Retter skrev:
>>> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
>>> algorithm developed by the NSA
>>
>> Can one be more open than this: http://tools.ietf.org/html/rfc3174
> 
> If I understand correctly, is that not just the implementation of the
> algorithm? SHA-1 has been proven several times to have weaknesses and
> each time its proven the feasibility of the attack has significantly
> increased. In fact the US Government now recommends that government
> departments use SHA-2 or better and not SHA-1.
> 
>> OpenJDK also supports SHA-2, eg the 224 variant
>> http://openjdk.java.net/jeps/130
> 
> Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160
> bits. RIPEMD-160 should be faster (less computationally intensive)
> than SHA-2 if I understand correctly, and in addition requires less
> memory and storage for the digest. Like SHA-1, SHA-2 was also
> developed in private in a proprietary way, unlike RIPEMD-160.
> 
>> --
>> peter
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Exist-development mailing list
>> Exi...@li...
>> https://lists.sourceforge.net/lists/listinfo/exist-development
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPMCTvhcIn5aVXOPIRAv76AJ9TdUzt9LGcwOYhGsAWzZYUhLvtQQCeLMkA
IbY3/nVmTrrQQ1StnS4wRuw=
=gfBy
-----END PGP SIGNATURE-----

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

Hi,  



On Monday, 6 February 2012 at 19:56 , Adam Retter wrote:

> If I understand correctly, is that not just the implementation of the
> algorithm? SHA-1 has been proven several times to have weaknesses and
> each time its proven the feasibility of the attack has significantly
> increased. In fact the US Government now recommends that government
> departments use SHA-2 or better and not SHA-1.


well we are not building a bank do we?  
  
> Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160bits. RIPEMD-160 should be faster (less computationally intensive)
> than SHA-2 if I understand correctly, and in addition requires less
> memory and storage for the digest. Like SHA-1, SHA-2 was also
> developed in private in a proprietary way, unlike RIPEMD-160.

I am sure that SHA-x  is well optimized in the JDK……… In the 'proprietary' I do not really see an argument, sorry :-) It is the result that counts, SHA-x is good…..

cheers

Dannes



--  
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

Sorry, was your agreement for RIPEMD or for SHA?


2012/2/6 Leif-Jöran Olsson <lj...@ex...>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yes, I agree with this. Though I must say someone med a very crappy
> decision when chosing this very subjective and not really motivated
> subject line. Could we move this to a clean thread?
>
> Cheers,
> Leif-Jöran
>
> Den 2012-02-06 19:56, Adam Retter skrev:
>>>> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
>>>> algorithm developed by the NSA
>>>
>>> Can one be more open than this: http://tools.ietf.org/html/rfc3174
>>
>> If I understand correctly, is that not just the implementation of the
>> algorithm? SHA-1 has been proven several times to have weaknesses and
>> each time its proven the feasibility of the attack has significantly
>> increased. In fact the US Government now recommends that government
>> departments use SHA-2 or better and not SHA-1.
>>
>>> OpenJDK also supports SHA-2, eg the 224 variant
>>> http://openjdk.java.net/jeps/130
>>
>> Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160
>> bits. RIPEMD-160 should be faster (less computationally intensive)
>> than SHA-2 if I understand correctly, and in addition requires less
>> memory and storage for the digest. Like SHA-1, SHA-2 was also
>> developed in private in a proprietary way, unlike RIPEMD-160.
>>
>>> --
>>> peter
>>>
>>> ------------------------------------------------------------------------------
>>> Try before you buy = See our experts in action!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-dev2
>>> _______________________________________________
>>> Exist-development mailing list
>>> Exi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/exist-development
>>
>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.18 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iD8DBQFPMCTvhcIn5aVXOPIRAv76AJ9TdUzt9LGcwOYhGsAWzZYUhLvtQQCeLMkA
> IbY3/nVmTrrQQ1StnS4wRuw=
> =gfBy
> -----END PGP SIGNATURE-----



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Leif-Jöran O. <lj...@ex...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It was for your arguments on ripemd. ;)

Den 2012-02-06 20:44, Adam Retter skrev:
> Sorry, was your agreement for RIPEMD or for SHA?
> 
> 
> 2012/2/6 Leif-Jöran Olsson <lj...@ex...>:
> Yes, I agree with this. Though I must say someone med a very crappy
> decision when chosing this very subjective and not really motivated
> subject line. Could we move this to a clean thread?
> 
> Cheers,
> Leif-Jöran
> 
> Den 2012-02-06 19:56, Adam Retter skrev:
>>>>>> I chose RIPEMD-160 over SHA because SHA is a closed proprietary
>>>>>> algorithm developed by the NSA
>>>>>
>>>>> Can one be more open than this: http://tools.ietf.org/html/rfc3174
>>>>
>>>> If I understand correctly, is that not just the implementation of the
>>>> algorithm? SHA-1 has been proven several times to have weaknesses and
>>>> each time its proven the feasibility of the attack has significantly
>>>> increased. In fact the US Government now recommends that government
>>>> departments use SHA-2 or better and not SHA-1.
>>>>
>>>>> OpenJDK also supports SHA-2, eg the 224 variant
>>>>> http://openjdk.java.net/jeps/130
>>>>
>>>> Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160
>>>> bits. RIPEMD-160 should be faster (less computationally intensive)
>>>> than SHA-2 if I understand correctly, and in addition requires less
>>>> memory and storage for the digest. Like SHA-1, SHA-2 was also
>>>> developed in private in a proprietary way, unlike RIPEMD-160.
>>>>
>>>>> --
>>>>> peter
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Try before you buy = See our experts in action!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-dev2
>>>>> _______________________________________________
>>>>> Exist-development mailing list
>>>>> Exi...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/exist-development
>>>>
>>>>
>>>>
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFPMDkGhcIn5aVXOPIRAnHoAJ0Q43hnoLsuaFTM0mj/xt0eZG+V4ACfWWLh
j39/izFXoWTAPv5d4hY5Z1U=
=L1SK
-----END PGP SIGNATURE-----

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Adam R. <ad...@ex...>]

> If I understand correctly, is that not just the implementation of the
> algorithm? SHA-1 has been proven several times to have weaknesses and
> each time its proven the feasibility of the attack has significantly
> increased. In fact the US Government now recommends that government
> departments use SHA-2 or better and not SHA-1.
>
>
> well we are not building a bank do we?

If I did not care about Security I would not have undertaken this work
or made the decisions that I made. I dont know if we are building a
bank, perhaps some eXist-db users do work in Banks. I did not choose
RIPEMD-160 because it is super secure, otherwise I would have chosen a
512bit algorithm or stronger. I chose it because it meets the security
criteria and its fast and a good compromise allround.

>
> Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just 160bits.
> RIPEMD-160 should be faster (less computationally intensive)
> than SHA-2 if I understand correctly, and in addition requires less
> memory and storage for the digest. Like SHA-1, SHA-2 was also
> developed in private in a proprietary way, unlike RIPEMD-160.
>
> I am sure that SHA-x  is well optimized in the JDK……… In the 'proprietary' I
> do not really see an argument, sorry :-) It is the result that counts, SHA-x
> is good…..

So you say its the result that counts, and that we must use SHA-1
because it is 'good'. What is it about RIPEMD that you believe is
'bad'? Also what is it about SHA-1 that is better? If the answer is
that SHA-1 is included in the JDK - thats a bad answer, because you
are answering a security concern with a technical limitation. I also
think that technical limitation is artificial, we use many JAR's where
functionality is not present in the JDK already, so why not here?


> cheers
>
> Dannes
>
>
>
> --
> eXist-db Native XML Database - http://exist-db.org
> Join us on linked-in: http://www.linkedin.com/groups?gid=35624
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dmitriy S. <sha...@gm...>]

We have too big war on very small peace of code. If it so, let's leave as
it, IMHO. or we will not find agreement.

+1 for configurable option at /db/system/security/config.xml

On Tue, Feb 7, 2012 at 12:48 AM, Adam Retter <ad...@ex...> wrote:

> > If I understand correctly, is that not just the implementation of the
> > algorithm? SHA-1 has been proven several times to have weaknesses and
> > each time its proven the feasibility of the attack has significantly
> > increased. In fact the US Government now recommends that government
> > departments use SHA-2 or better and not SHA-1.
> >
> >
> > well we are not building a bank do we?
>
> If I did not care about Security I would not have undertaken this work
> or made the decisions that I made. I dont know if we are building a
> bank, perhaps some eXist-db users do work in Banks. I did not choose
> RIPEMD-160 because it is super secure, otherwise I would have chosen a
> 512bit algorithm or stronger. I chose it because it meets the security
> criteria and its fast and a good compromise allround.
>
> >
> > Yes there is SHA-2, however its 256bit whereas RIPEMD-160 is just
> 160bits.
> > RIPEMD-160 should be faster (less computationally intensive)
> > than SHA-2 if I understand correctly, and in addition requires less
> > memory and storage for the digest. Like SHA-1, SHA-2 was also
> > developed in private in a proprietary way, unlike RIPEMD-160.
> >
> > I am sure that SHA-x  is well optimized in the JDK……… In the
> 'proprietary' I
> > do not really see an argument, sorry :-) It is the result that counts,
> SHA-x
> > is good…..
>
> So you say its the result that counts, and that we must use SHA-1
> because it is 'good'. What is it about RIPEMD that you believe is
> 'bad'? Also what is it about SHA-1 that is better? If the answer is
> that SHA-1 is included in the JDK - thats a bad answer, because you
> are answering a security concern with a technical limitation. I also
> think that technical limitation is artificial, we use many JAR's where
> functionality is not present in the JDK already, so why not here?
>

-- 
Dmitriy Shabanov

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

Hi

On Monday, 6 February 2012 at 20:52 , Dmitriy Shabanov wrote:

> We have too big war on very small peace of code

right, somehow trying to discuss via mail does not work………




--  
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624
  

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Loren C. <lor...@gm...>]

Can we save this discussion for Friday in Prague?  I think that this discussion would be best face-to-face (preferable with beer as the lubricant to the discussion). 

When do you folks arrive?  I will be arriving on Wednesday.

Re: [Exist-development] LGPL 2.1 and GPL 2 and all that crap

[Dannes W. <da...@ex...>]

face2face discussion would be good, but….. we all must be willing to be open for reasonable arguments. So far……. hmmmm

--  
eXist-db Native XML Database - http://exist-db.org
Join us on linked-in: http://www.linkedin.com/groups?gid=35624


On Monday, 6 February 2012 at 20:54 , Loren Cahlander wrote:

> Can we save this discussion for Friday in Prague? I think that this discussion would be best face-to-face (preferable with beer as the lubricant to the discussion).  

Re: [Exist-development] Security

[Hungerburg <pc...@my...>]

Thank you Adam for taking the time to justify your decision. I 
understand that it is not easy on anybody, to feel prommpted to justify 
one’s efforts.

I cannot argue about the cost of 256 vs 160 bytes per digest or 
processing power/number of instructions per digestification (what a 
funny word, should it be digestion :). I consider the SHA reference 
implementation fairly good documented though, and I believe in that it 
has gotten quite a lot of scrutiny by the experts in the field, and so 
it seemed wrong to me, to describe it in such a way.

Just like you, I think security has to be accounted for with a straight 
face. Why not provide the same security as a bank does, if it is 
affordable? World famous Bruce Schneier does not get tired of saying, 
that security is a trade-off. So,

I wish you all a happy bargaining in Prague.

While I will enjoy my beer at home, may I suggest two more points to the 
security debate (in the interest of the eXist project, in my humble view):

# Exposing all of db through the "apps" namespace in addition to the 
"rest" namespace, from the "security is a process" standpoint, does not 
look a good decision. MVC theory instead proposes, to store 
(confidential) data outside of the web-root.

# I have the gut feeling, that by requesting a restricted resource from 
"rest" space, thereby adding credentials via http-auth, that this 
creates a server side session, allowing me to browse "admin.xql" without 
being prompted for login. Rest is said to be stateless, though.

I hope, this sounds sufficiently sober to be considered.

Yours

Peter

Re: [Exist-development] Security

[Adam R. <ad...@ex...>]

> # Exposing all of db through the "apps" namespace in addition to the "rest"
> namespace, from the "security is a process" standpoint, does not look a good
> decision. MVC theory instead proposes, to store (confidential) data outside
> of the web-root.

Yes I agree the security concerns here are bad.

> # I have the gut feeling, that by requesting a restricted resource from
> "rest" space, thereby adding credentials via http-auth, that this creates a
> server side session, allowing me to browse "admin.xql" without being
> prompted for login. Rest is said to be stateless, though.

Yes that is the case.

> I hope, this sounds sufficiently sober to be considered.

I plan to launch Project Sleepy at Prague. This should solve both of
your above concerns I hope.

> Yours
>
> Peter
>



-- 
Adam Retter

eXist Developer
{ United Kingdom }
ad...@ex...
irc://irc.freenode.net/existdb

Re: [Exist-development] Security

[Thomas W. <tho...@gm...>]

On 6 February 2012 23:14, Hungerburg <pc...@my...> wrote:

> # Exposing all of db through the "apps" namespace in addition to the
> "rest" namespace, from the "security is a process" standpoint, does not
> look a good decision. MVC theory instead proposes, to store
> (confidential) data outside of the web-root.
>
>
I agree to expose the whole db under /apps is not a very good idea. When
give access to the db we should limit it to a collection that is dedicated
for this purpose. Something like /db/apps. This way there will be a clear
separation between the data and the applications, nicely located in a
single place. The application's code will access the rest of the db if and
when needed in a controlled manner.

So my proposition is to change the redirection /apps - > /db    to /apps ->
/db/apps

Thomas

Re: [Exist-development] Security

[Hungerburg <pc...@my...>]

Am 2012-02-07 10:48, schrieb Thomas White:
>
> On 6 February 2012 23:14, Hungerburg <pc...@my...
> <mailto:pc...@my...>> wrote:
>
>     # Exposing all of db through the "apps" namespace in addition to the
>     "rest" namespace, from the "security is a process" standpoint, does not
>     look a good decision. MVC theory instead proposes, to store
>     (confidential) data outside of the web-root.
>
>
> I agree to expose the whole db under /apps is not a very good idea. When
> give access to the db we should limit it to a collection that is
> dedicated for this purpose. Something like /db/apps. This way there will
> be a clear separation between the data and the applications, nicely
> located in a single place. The application's code will access the rest
> of the db if and when needed in a controlled manner.

The security consideration is that, when data is not reachable, except 
through the controller, the controller is not responsible for hiding the 
data. So there is one less mistake, a developer can make, eg. forgetting 
to shadow some part of db (rest space being disabled). Developers still 
can make mistakes...

> So my proposition is to change the redirection /apps - > /db    to /apps
> -> /db/apps

Of course, this will make app development trickier. A simple app migth 
still be deployed by unzipping files below a single root in /apps. Where 
sensitive data is handled, the app would be dual rooted then though. The 
public part below /apps and the private part below /db/foo for example. 
Path constructions get more cumbersome, relocating apps will be more 
difficult too, etc. But for eg. medical records or other personal data, 
this is a must, isnt it?

-- 
peter

Re: [Exist-development] Security

[Wolfgang M. <wol...@ex...>]

> I agree to expose the whole db under /apps is not a very good idea. When
> give access to the db we should limit it to a collection that is dedicated
> for this purpose. Something like /db/apps.

Indeed we already discussed this here before and the decision was to
use /db/apps as the root for all apps. I just had no time to make the
required changes so far.

Wolfgang

Re: [Exist-development] Security

[Patrick B. <pat...@jo...>]

I feel like I may have missed part of this conversation, so I
apologize in advance if my question is irrelevant.

Does the proposal to move apps to /db/apps mean that only .xql under
/db/apps would be able to be executed?


Cheers,

Patrick

On Tue, Feb 7, 2012 at 5:10 AM, Wolfgang Meier <wol...@ex...> wrote:
>> I agree to expose the whole db under /apps is not a very good idea. When
>> give access to the db we should limit it to a collection that is dedicated
>> for this purpose. Something like /db/apps.
>
> Indeed we already discussed this here before and the decision was to
> use /db/apps as the root for all apps. I just had no time to make the
> required changes so far.
>
> Wolfgang
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development



-- 
Patrick Bosek
Jorsek Software
Cell (585) 820 9634
Office (877) 492 2960
Jorsek.com

Re: [Exist-development] Security

[Dmitriy S. <sha...@gm...>]

On Tue, Feb 7, 2012 at 6:27 PM, Patrick Bosek <pat...@jo...>wrote:

> I feel like I may have missed part of this conversation, so I
> apologize in advance if my question is irrelevant.
>
> Does the proposal to move apps to /db/apps mean that only .xql under
> /db/apps would be able to be executed?
>

No, that is the question of default mapping, but this mapping can be
changed any time.

-- 
Dmitriy Shabanov