On Thu, Apr 11, 2013 at 09:11:27AM +0100, Joe wrote:
> turn it off if so configured. Later and later versions of PHP have
> become much stricter in many ways, and have offered features like
> Perl's optional variable discipline, so many of the Suhosin features are
What does "optional variable disc
On Fri, 12 Apr 2013 03:56:31 +1000
Andrew McGlashan wrote:
>
> If data is passed via forms or via GET or POST and that data isn't
> properly handled by php itself, then it may produce a buffer overrun
> situation ... possibly before the data gets passed through to the
> webpage code; if this c
On 11/04/2013 6:11 PM, Joe wrote:
> A working commercial PHP programmer probably could, but I'm not sure it
> would help. PHP is a programming language, running on a web server,
> which needs to access the server's databases, drives, memory etc.
> There's no way it can be made secure, any more than
On Thu, 11 Apr 2013 15:57:03 +1000
Andrew McGlashan wrote:
> On 11/04/2013 3:21 PM, Bob Proulx wrote:
> > Andrew McGlashan wrote:
> >> Yes, but insecure code is so easy to make and even the so called
> >> experts are making them. There is even an O'Reilly book that has
> >> wrong information tha
On 11/04/2013 3:21 PM, Bob Proulx wrote:
> Andrew McGlashan wrote:
>> Yes, but insecure code is so easy to make and even the so called experts
>> are making them. There is even an O'Reilly book that has wrong
>> information that is leading programmers astray. The protections
>> provided by Suhosi
Andrew McGlashan wrote:
> Yes, but insecure code is so easy to make and even the so called experts
> are making them. There is even an O'Reilly book that has wrong
> information that is leading programmers astray. The protections
> provided by Suhosin in the past may _always_ be required and nece
On 11/04/2013 5:40 AM, Bob Proulx wrote:
> What I have read (caution unverified) is that the PHP interpreter
> isn't intrinsically insecure. It only becomes that way when used with
> insecure php code. Which makes sense. Any upstream interpreter
> vulnerability would have a CVE number associated
Andrew McGlashan wrote:
> To cut a long story short, if PHP upstream has incorporated the features
> of Suhosin, then we should be fine; is it the final conclusion from that
> long thread and all the references from it, that we are in good shape
> with 5.4.4 -- better than pre 5.4 with Suhosin?
To
Hi Bob,
On 11/04/2013 3:26 AM, Bob Proulx wrote:
> Andrew McGlashan wrote:
>> Now, php5-suhosin provides some real protection against programming
>> problems that could very easily exist and it is not uncommon to see
>> messages from Debian stable installs reporting bugs / vulnerabilities
>> detec
Andrew McGlashan wrote:
> Now, php5-suhosin provides some real protection against programming
> problems that could very easily exist and it is not uncommon to see
> messages from Debian stable installs reporting bugs / vulnerabilities
> detected by suhosin
The question isn't whether the suhos
On Wed, Apr 10, 2013 at 01:54:43PM +0200, "Morel Bérenger" wrote:
> Le Mer 10 avril 2013 12:36, Andrew McGlashan a écrit :
> > Will php5-suhosin be re-instated any time soon?
>
> I have no clue about what instated means :)
https://en.wiktionary.org/wiki/reinstate
signature.asc
Description: Dig
Le Mer 10 avril 2013 12:36, Andrew McGlashan a écrit :
> Will php5-suhosin be re-instated any time soon?
I have no clue about what instated means :)
> And if not, what
> measures can we take to protect Wheezy servers now?
Maybe you can reuse the old package.
Check the dependencies, it is possibl
Hi,
I'm working on a server replacement, the old (current) server is running
latest stable release and the new server is running from this downloaded
installer ISO:
debian-wheezy-DI-rc1-amd64-netinst.iso
Now, php5-suhosin provides some real protection against programming
problems that could
13 matches
Mail list logo
