HSQLDB security risks

[Steve Loughran <st...@gmail.com>]

Here's an interesting thought. HSQLDB has just had a security risk
raised against it:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4575


The repository stops at version 1.8.0.7 :
http://repo1.maven.org/maven2/hsqldb/hsqldb/
this is still vulnerable

Also, a truck load of other artifacts still depend on it:
http://www.mvnrepository.com/artifact/hsqldb/hsqldb/1.8.0.7

Clearly we need to get the 1.8.0.9 release up there ASAP; if nobody
wants to update the existing 1.8.0.7 POM for this I can do it @work
next week (we use it for testing only, not redistribution).

More subtly: should the existing artifacts be left alone? We could
delete them, which would force everyone to move up to a secure
version, but break builds. Or we could put some redirect in, perhaps?
I know this goes against the philosopy of once-published-never-touch,
and doesnt solve the real problem, which is everyone who redists
hqsldb drivers needs to know the risk and re-release their app if
vulnerable.

Perhaps we need some notion of 'danger artifacts' -and refuse to
accept any more products who declare a dependency on hsqldb < 1.8.0.9?
That way, we can stop any more references to unsafe artifacts creeping
in?

-steve

Re: HSQLDB security risks

[Carlos Sanchez <ca...@apache.org>]

>From my point of view the repository is just a library, we make it
available and other people will make the decisions of what they want
to use. I don't see ourselves as a police saying what has to be used
and what not.

my 0.02

On Jan 19, 2008 1:19 PM, Matthieu Riou <ma...@offthelip.org> wrote:
>
> On Jan 19, 2008 12:52 PM, Steve Loughran <st...@gmail.com> wrote:
>
>
> > Here's an interesting thought. HSQLDB has just had a security risk
> > raised against it:
> >
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4575
> >
> >
> > The repository stops at version 1.8.0.7 :
> > http://repo1.maven.org/maven2/hsqldb/hsqldb/
> > this is still vulnerable
> >
> > Also, a truck load of other artifacts still depend on it:
> > http://www.mvnrepository.com/artifact/hsqldb/hsqldb/1.8.0.7
> >
> > Clearly we need to get the 1.8.0.9 release up there ASAP; if nobody
> > wants to update the existing 1.8.0.7 POM for this I can do it @work
> > next week (we use it for testing only, not redistribution).
> >
> > More subtly: should the existing artifacts be left alone? We could
> > delete them, which would force everyone to move up to a secure
> > version, but break builds. Or we could put some redirect in, perhaps?
> > I know this goes against the philosopy of once-published-never-touch,
> > and doesnt solve the real problem, which is everyone who redists
> > hqsldb drivers needs to know the risk and re-release their app if
> > vulnerable.
> >
> > Perhaps we need some notion of 'danger artifacts' -and refuse to
> > accept any more products who declare a dependency on hsqldb < 1.8.0.9?
> > That way, we can stop any more references to unsafe artifacts creeping
> > in?
> >
>
> Having a 1.8.0.9 in the repo is definitely nice to have but I can think of
> quite of few scenarios where this security hole doesn't apply, like when
> HSQL is just used in-VM for testing. Breaking everybody's build because
> there's a security hole they'll never see in their test database is maybe
> not a good idea...
>
> Matthieu
>
> >
> > -steve
> >
>
>



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

Re: HSQLDB security risks

[Matthieu Riou <ma...@offthelip.org>]

On Jan 19, 2008 12:52 PM, Steve Loughran <st...@gmail.com> wrote:

> Here's an interesting thought. HSQLDB has just had a security risk
> raised against it:
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4575
>
>
> The repository stops at version 1.8.0.7 :
> http://repo1.maven.org/maven2/hsqldb/hsqldb/
> this is still vulnerable
>
> Also, a truck load of other artifacts still depend on it:
> http://www.mvnrepository.com/artifact/hsqldb/hsqldb/1.8.0.7
>
> Clearly we need to get the 1.8.0.9 release up there ASAP; if nobody
> wants to update the existing 1.8.0.7 POM for this I can do it @work
> next week (we use it for testing only, not redistribution).
>
> More subtly: should the existing artifacts be left alone? We could
> delete them, which would force everyone to move up to a secure
> version, but break builds. Or we could put some redirect in, perhaps?
> I know this goes against the philosopy of once-published-never-touch,
> and doesnt solve the real problem, which is everyone who redists
> hqsldb drivers needs to know the risk and re-release their app if
> vulnerable.
>
> Perhaps we need some notion of 'danger artifacts' -and refuse to
> accept any more products who declare a dependency on hsqldb < 1.8.0.9?
> That way, we can stop any more references to unsafe artifacts creeping
> in?
>

Having a 1.8.0.9 in the repo is definitely nice to have but I can think of
quite of few scenarios where this security hole doesn't apply, like when
HSQL is just used in-VM for testing. Breaking everybody's build because
there's a security hole they'll never see in their test database is maybe
not a good idea...

Matthieu


>
> -steve
>