[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnump3d-users] A few 2.7 Issues

From: Steve Kemp
Subject: Re: [Gnump3d-users] A few 2.7 Issues
Date: Tue, 1 Nov 2005 17:30:22 +0000
User-agent: Mutt/1.5.9i

On Tue, Nov 01, 2005 at 10:18:03AM -0500, koan wrote:

>    This is a 2 part email regarding what appears to be a bug and also minor
>    enhancement request


>    Fist off this is a Slackware 10.2 box / Perl 5.8.7 / GNUMP3d 2.7


>    When navigate go to my gnump3d server which is configured for password
>    protection, and purposly fail the login prompt, the child perl process
>    uses ~50% CPU indefinately and spews this repeatedly to the error log:

>    Use of uninitialized value in length at (eval 26) line 414.
>    Use of uninitialized value in pattern match (m//) at (eval 26) line 397.
>    Use of uninitialized value in pattern match (m//) at (eval 26) line 405.

  That sounds bad.  I'll see if I can verify it myself tomorrow when
 I'm infront of my own host.

>    I only allowed it to run for 15 minutes, but it appears to be an infinite
>    loop. Has anyone see anything similar ?

  I've not had it reported previously, but if I can confirm it I will
 of course fix it.

>    Issue 2:
>    ------------
>    It seems to me that on a failed login attempt (and I would assume a denied
>    host - although I havn't tested that one) that, as a matter of course, the
>    server should disclose as little information as possible about the service
>    to which access was denied.

  That is a valid concern.

>    Currently upon bad login you are greeted with a fully templated error page
>    that states both the applications name and exact revision.
>    Would it be possible to add an option for a "sparse" error page on access
>    denied?


  However you *can* edit the error page yourself, via the theme files.

  If you're using the 'default' template set you'll find the file:


  You can edit/"sparsen" that file as you see fit.

  The reason I'm saying no here is because I consider the general case
 of users running the server to be upon a trusted LAN.  I don't believe
 that the majority of users run the code upon publically accessible
 machines - so the majority of users who will see an error message
 deserve to see as much information as they can.

  So whilst I'm agreeing that there is information disclosure I 
 will not accept a change in the default unless a significant number
 of users ask for it.  

  Sorry .. :S


reply via email to

[Prev in Thread] Current Thread [Next in Thread]