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