exist-development — eXist Developer's List

Re: [Exist-development] [HEADS-UP] Merge in of Security Branch

[Joe W. <jo...@gm...>]

Absolutely!  Thanks for all your hard work on this, Adam!

Joe

On Mon, Feb 6, 2012 at 3:22 PM, Patrick Bosek <pat...@jo...> wrote:
> This is excellent news!
>
> On Mon, Feb 6, 2012 at 2:26 AM, Dannes Wessels <da...@ex...> wrote:
>> Hi,
>>
>> Thank you for your hard word of the last weeks.........

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] [HEADS-UP] Merge in of Security Branch

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

This is excellent news!

On Mon, Feb 6, 2012 at 2:26 AM, Dannes Wessels <da...@ex...> wrote:
> Hi,
>
> Thank you for your hard word of the last weeks.........
>
> On Sun, Feb 5, 2012 at 11:53 PM, Adam Retter <ad...@ex...> wrote:
>>
>> 5) Password hashing has changed from MD5 to RIPEMD-160. There are too
>> many rainbow tables available for MD5, which makes revealing an MD5
>> password an absolute snip. RIPEMD-160 should be much tougher to crack,
>> or calculate all permutations. Should anyone ask, I chose RIPEMD-160
>> over SHA-256 because of political concerns.
>
>
> I think having 'just another' jar file for cryptography is a bad idea. The
> JVM provides sufficient 'open' encryption/hashing techniques, which can be
> used (the 'sensitive encryption techniques' used to be an optional download
> anyway).
>
> I'd vote for stick to the JVM's JSSE technology. Please could you elaborate
> on the "political concerns" ?
>
> cheers
>
> Danes
>
>
> --
> eXist-db Native XML Database - http://exist-db.org
> Join us on linked-in: http://www.linkedin.com/groups?gid=35624
>
> ------------------------------------------------------------------------------
> 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
>



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

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

[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

[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

[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

[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

[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

[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: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...>]

>> 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

[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

[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

[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

[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] [HEADS-UP] Merge in of Security Branch

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

Hi,

Thank you for your hard word of the last weeks.........

On Sun, Feb 5, 2012 at 11:53 PM, Adam Retter <ad...@ex...> wrote:

> 5) Password hashing has changed from MD5 to RIPEMD-160. There are too
> many rainbow tables available for MD5, which makes revealing an MD5
> password an absolute snip. RIPEMD-160 should be much tougher to crack,
> or calculate all permutations. Should anyone ask, I chose RIPEMD-160
> over SHA-256 because of political concerns.
>

I think having 'just another' jar file for cryptography is a bad idea. The
JVM provides sufficient 'open' encryption/hashing techniques, which can be
used (the 'sensitive encryption techniques' used to be an optional download
anyway).

I'd vote for stick to the JVM's JSSE technology. Please could you elaborate
on the "political concerns" ?

cheers

Danes


-- 
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

[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

[Joe W. <jo...@gm...>]

Adam - please disregard my email below.  I see you addressed this
question already in your heads up about the security updates merge in.

Joe

On Sun, Feb 5, 2012 at 6:42 PM, Joe Wicentowski <jo...@gm...> wrote:
> Hi Adam,
>
> Maybe you've already resolved the licensing question.  But I gather that the code in question was used to add a hash method more secure than MD5, RIPEMD-160.  Is there a reason you didn't just use any of the SHA variants that are already in eXist, rather than adding a new crypto library?
>
> Joe
>
> Sent from my iPad
>
> On Feb 5, 2012, at 3:48 PM, Adam Retter <ad...@ex...> wrote:
>
>> 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.
>>
>> --
>> Adam Retter
>>
>> eXist Developer
>> { United Kingdom }
>> ad...@ex...
>> irc://irc.freenode.net/existdb
>>
>> ------------------------------------------------------------------------------
>> 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

[Joe W. <jo...@gm...>]

Hi Adam,

Maybe you've already resolved the licensing question.  But I gather that the code in question was used to add a hash method more secure than MD5, RIPEMD-160.  Is there a reason you didn't just use any of the SHA variants that are already in eXist, rather than adding a new crypto library?  

Joe

Sent from my iPad

On Feb 5, 2012, at 3:48 PM, Adam Retter <ad...@ex...> wrote:

> 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.
> 
> -- 
> Adam Retter
> 
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
> 
> ------------------------------------------------------------------------------
> 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

[Exist-development] [HEADS-UP] Merge in of Security Branch

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

Hey Everyone,

I have just merged the Security Branch into trunk as revision 15806.
This is the latest round of security changes. The main things to look
out for -

1) Permissions should now adhere to the Unix permissions model. All
permission checks on core database operations should now be correct. I
have documented these in $EXIST_HOME/webapp/security.xml in the
'Operational Permissions' section.

2) Permissions are now rigorously enforced, so if your application
relied on lax permissions in eXist-db before then you will need to
make some small changes.

3) The 'u' update flag has been removed. Update really always meant
the same as Write anyway, so the Write flag covers all writes to
Resources now. The execute 'x' flag replaces that. Execute controls
the ability to a) Enter a Collection (just like a folder in Unix) and
b) to execute an XQuery script (just like shell scripts and bin's in
Unix).

4) Default permissions now follow the Unix model of 755 for
Collections i.e. rwxr-xr-x (including /db) and 644 for Resources i.e.
rw-r--r--
There is the facility in place for a umask, I will begin to expose
that along with setUID and setGID options in the near future.
NOTE - this means that XQuery scripts are no longer executable by
default (from a security perspective, thats important!). You will need
to set the 'x' flag on your XQuery scripts appropriately, so you can
now control execution by Owner/Group/World/ACL.

5) Password hashing has changed from MD5 to RIPEMD-160. There are too
many rainbow tables available for MD5, which makes revealing an MD5
password an absolute snip. RIPEMD-160 should be much tougher to crack,
or calculate all permutations. Should anyone ask, I chose RIPEMD-160
over SHA-256 because of political concerns.

6) ACLs and ACEs are done. These will be demo'd in Prague at the
eXist-db meetup day and written up shortly after.

7) eXist-db is now multi-realm. As such you can authenticate users
from disparate sources transparently. There is now decent support for
LDAP (including Active Directory) and embryonic support for OpenID and
OAuth. These will also be documented in the near future.

8) There is a new SecurityManager XQuery module of functions. This
should be considered the module to use for security, user and
permission operations. The equivalent functions in the XMLDB Module
are deprecated and any remaining functions will be moved into this
module in the near future.

If you want to help... I need testing and feedback please :-)

-- 
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

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

Adam,

I hope this link could be of help.
http://www.freesoftwaremagazine.com/articles/choosing_and_using_free_licenses_software_hardware_and_aesthetic_works

Thomas


------

Thomas White

Mobile:+44 7711 922 966
Skype: thomaswhite
gTalk: thomas.0007
http://www.linkedin.com/in/thomaswhite0007
http://www.facebook.com/thomas.0007



On 5 February 2012 21:57, Adam Retter <ad...@ex...> wrote:

> Thanks Alain,
>
> The thing I was using under GPL was GNU Crypto, but I just checked
> their licence in more details and it seems that we should be fine as
> it says -
>
> "GNU Crypto is licensed under the terms of the GNU General Public
> License, with the "library exception" which permits its use as a
> library in conjunction with non-Free software:
>
> "As a special exception, the copyright holders of this library give
> you permission to link this library with independent modules to
> produce an executable, regardless of the license terms of these
> independent modules, and to copy and distribute the resulting
> executable under terms of your choice, provided that you also meet,
> for each linked independent module, the terms and conditions of the
> license of that module. An independent module is a module which is not
> derived from or based on this library. If you modify this library, you
> may extend this exception to your version of the library, but you are
> not obligated to do so. If you do not wish to do so, delete this
> exception statement from your version."
> The effect of that license is similar to using the LGPL, except that
> static linking is permitted. GPL with that exception is sometimes
> called the Guile License, because the Guile implementation of Scheme
> (for embedding) uses this license."
>
> So as I am using it as a JAR, I dont think I need worry now...
>
> On 5 February 2012 21:25, Alain Couthures <ala...@ag...>
> 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.
> >>>>
> >>
> >>
> >
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
>
> ------------------------------------------------------------------------------
> 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

[Luigi B. <lp...@ka...>]

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

[<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

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

Thanks Alain,

The thing I was using under GPL was GNU Crypto, but I just checked
their licence in more details and it seems that we should be fine as
it says -

"GNU Crypto is licensed under the terms of the GNU General Public
License, with the "library exception" which permits its use as a
library in conjunction with non-Free software:

"As a special exception, the copyright holders of this library give
you permission to link this library with independent modules to
produce an executable, regardless of the license terms of these
independent modules, and to copy and distribute the resulting
executable under terms of your choice, provided that you also meet,
for each linked independent module, the terms and conditions of the
license of that module. An independent module is a module which is not
derived from or based on this library. If you modify this library, you
may extend this exception to your version of the library, but you are
not obligated to do so. If you do not wish to do so, delete this
exception statement from your version."
The effect of that license is similar to using the LGPL, except that
static linking is permitted. GPL with that exception is sometimes
called the Guile License, because the Guile implementation of Scheme
(for embedding) uses this license."

So as I am using it as a JAR, I dont think I need worry now...

On 5 February 2012 21:25, Alain Couthures <ala...@ag...> 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.
>>>>
>>
>>
>



-- 
Adam Retter

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