On 9/9/2023 3:18 AM, Bob Gezelter wrote:
> On Thursday, September 7, 2023 at 8:38:21 AM UTC-4, Simon Clubley wrote:
>> On 2023-09-06, Chris Townley <ne...@cct-net.co.uk> wrote:
>>>
>>> But plenty of youngsters play with Raspberry Pis - they don't even come
>>> with a box!
>>>
>> Yes, but what are they doing with them ?
>>
>> Quite a bit of the time it appears to be doing clever things with
>> user-mode applications that already exist.
>>
>> At one end, I can write bare-metal startup code and hence understand
>> how computers work when you have no software layers between you and the
>> hardware.
>>
>> At the other end, I can write business and webserver applications.
>>
>> I can also do the full range of intermediate stuff including writing
>> device drivers, and system-level programming in general.
>>
>> Like Scott, I get the feeling that understanding the system-level
>> stuff isn't as common any more (sadly).
>> Simon.
>>
>> --
>> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>> Walking destinations on a map are further away than they appear.
> Simon,
>
> Sadly true. It profoundly unsettling to see the lack of underlying knowledge. Simple foundational knowledge about CPUs, memory, mass storage, networks, operating systems, and other areas is lacking. Often the common thread is ubiquity: Since all of the infrastructure has become commonplace, the everyday need for understanding has become background.
>
> However, in the end, everything in computing must tie back to the fundamentals. No amount of high-level abstraction can remove the realities of the foundational. One cannot take away the foundation by adding levels of abstraction and, in effect, obfuscation.

Truer than even you can imagine. Having started in the computer
biz as a GI and then moving on to government contracting (as a
systems engineer) with no degree but lots of experience I am amazed
at the current arguments over whether or not degrees are worth the
cost. I spent over 25 years in academia after my beltway bandit days
and I can assure you that the current graduate doesn't have half the
knowledge I had when I was just a lowly GI Programmer/Analyst.

bill

bill <bill.gunshannon@gmail.com> wrote:
>
>I had to support it at the University because we had a professor
>who insisted on teaching it, using it and making his students use
>it. No matter how many time I showed him the security holes he
>just insisted I was wrong and that it be available and wide open.

Don't show the professor the security holes. Show them to the students.
The result is always much more satisfying.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Bob Gezelter <gezelter@rlgsc.com> wrote:
>Sadly true. It profoundly unsettling to see the lack of underlying knowledg=
>e. Simple foundational knowledge about CPUs, memory, mass storage, networks=
>, operating systems, and other areas is lacking. Often the common thread is=
> ubiquity: Since all of the infrastructure has become commonplace, the ever=
>yday need for understanding has become background.

Our IT department back in 2016 went on a binge of getting rid of anything
that was on the inventory as a "laptop" or "portable computer" that could not
have the hard drive encrypted.

This meant we got rid of a bunch of older machines that were used for
instrument control, which did not boot off a hard drive and therefore
could not be encrypted.

But most interestingly it meant we got rid of a whole bunch of mechanical
slide rule devices (E-6B flight computers) because they could not be
encrypted.

I attempted to get the IT department to actually explain what a computer was
and what wasn't a computer, and to this day I still cannot get them to give
me a definition for what a computer is. I blame poor elementary school
education for this.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9/8/2023 2:05 PM, Simon Clubley wrote:
> Unfortunately, I _do_ have to use PHP sometimes.
>
> It didn't take me long to establish some solid rules, such as strict
> comparisons at _all_ times, and to use a monitor library I wrote that
> has the allowed error level turned all the way down so that things
> which PHP normally allows through generate an error instead.
>
> |PHP is built to keep chugging along at all costs. When faced with either
> |doing something nonsensical or aborting with an error, it will do something
> |nonsensical. Anything is better than nothing.
>
> It is a horrible, horrible, language that like Javascript has been
> turned from something used for writing little scripts into something
> used to write mission-critical and highly sensitive applications,
> which neither of them are suitable for.
>
> From that page:
>
> |PHP is built to keep chugging along at all costs. When faced with either
> |doing something nonsensical or aborting with an error, it will do something
> |nonsensical. Anything is better than nothing.
>
> That sums up the language perfectly (and the same mindset is equally true
> for Javascript in IMHO). They were both designed for quick hacks, not for
> serious mission-critical applications.

PHP actually follows the same rules as most languages:
not able to continue => error
able to continue => warning
error => stop execution
warning => continue execution

But PHP does allow some constructs that other languages do not.

As an example:

<?php

class C { }

function check($lbl, $v) {
$vv = $v ? 'true' : 'false';
echo "$lbl is $vv\r\n";
}

check('true', true);
check('false', false);
check('123', 123);
check('"ABC"', 'ABC');
check('0', 0);
check('""', '');
check('"0"', '0');
check('(instance of C)', new C());
check('null', null);

?>

outputs:

true is true
false is false
123 is true
"ABC" is true
0 is false
"" is false
"0" is false
(instance of C) is true
null is false

But languages get designed for certain purposes/contexts/users.

PHP was designed to allow people that does not understand
data types to write code.

If people do not understand the difference between boolean
data type and other data types, then PHP behavior makes sense.

There is little point in criticizing a language for meeting
its design goals.

The question is whether the language is a good choice for
a specific context.

I have no idea whether PHP was the right or the wrong choice
for your web application.

There is a pretty big majority in the IT industry that believe
type safe languages are not the right choice for web applications.
Business critical web site or not.

Just like you can ask a C compiler to not continue with
warnings then you can do the same with PHP.

function always_die($errno, $errstr, $errfile, $errline ) {
echo "$errstr in $errfile on line $errline";
die();
} set_error_handler('always_die');

will force PHP to stop at warnings and notices (PHP term for
informationals).

Arne

bill <bill.gunshannon@gmail.com> wrote:
>Truer than even you can imagine. Having started in the computer
>biz as a GI and then moving on to government contracting (as a
>systems engineer) with no degree but lots of experience I am amazed
>at the current arguments over whether or not degrees are worth the
>cost. I spent over 25 years in academia after my beltway bandit days
>and I can assure you that the current graduate doesn't have half the
>knowledge I had when I was just a lowly GI Programmer/Analyst.

I see fresh-outs who come with CS degrees from colleges that follow the
ACM curriculum who have a pretty good grip on the basics.

I also see fresh-outs who come with CS degrees from Hooterville Bible
College who have never used a command line, have never used any OS
other than Windows, and have never seen Big-O notation. They have a
CS degree on paper, but what they really got was a trade school education
in how to write code and they know nothing of actual CS.

But then... I see engineering fresh-outs who have never used a computer
for anything other than Word and Matlab and have no concept of embedded
stuff. I don't expect engineering students to learn a whole lot of real
computer science but I do expect them to have basic computer literacy skills.

There is a huge range.

I also see self-taught people and they can be interesting because they are
always very motivated (which is how they got to be self-taught in the first
place) but often have odd holes in their knowledge that they don't realize
exist. If you let them know about the holes they will fix them but they
often don't get to know about them until it's too late. The older they get
the better they get, and that's not always the case for folks with degrees.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9/8/2023 12:40 PM, bill wrote:
> On 9/8/2023 10:03 AM, Dan Cross wrote:
>> In article <km0l0iF8emlU3@mid.individual.net>,
>> bill  <bill.gunshannon@gmail.com> wrote:
>>> On 9/7/2023 9:18 AM, Dave Froble wrote:
>>>> My moment of enlightenment was the day I was told I wasn't a "real
>>>> programmer" since I didn't know or use PHP.  Guy didn't even know what
>>>> assembly language was.  It's actually a bit scary.
>>>
>>> I'm a real programmer.  I know PHP and that's why I don't use it.
>>
>> This seems apropos:
>> https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
>
> That was good.  Even some stuff in there I didn't already know about.
> But my biggest argument was how it works so very hard to make security
> in the environment it is most used (the web) totally nonexistent.

Totally opposite.

PHP does not have many of the common general flaws like
buffer overflow and memory leak.

PHP got all the features needing for secure web applications.

Some old features that were questionable from a security
perspective has been removed. Classic example is register_globals
that been off by default since version 4.2 (21 years ago) and
was finally removed in version 5.4 (8 years ago).

The most widely used frameworks has added features to make it
easy to avoid common web security problems. Example: Laravel
always check for token to prevent CSRF.

There is every reason to believe that a PHP web application
created by the average Ada/C++/Scala programmer would be very
secure.

A PHP application created by the average PGP programmer
is likely to have big security problems though.

There may be a million people doing PHP professionally, but
there are many millions doing PHP for hobby programming.

PHP has a big problem. It is an easy language to learn and
it is quite easy to get some PHP code working. Any idiot can
write PHP code that works - works in the good case that is.
So a lot of the idiots does write PHP code.

And we see one disaster after the other.

But that is not really PHP's problem. Unless we consider a
language being too easy to use as a flaw.

Arne

On 9/8/2023 6:59 PM, bill wrote:
> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>> Unfortunately, I _do_ have to use PHP sometimes.
>>
>> It didn't take me long to establish some solid rules, such as strict
>> comparisons at _all_ times, and to use a monitor library I wrote that
>> has the allowed error level turned all the way down so that things
>> which PHP normally allows through generate an error instead.
>
> I had to support it at the University because we had a professor
> who insisted on teaching it, using it and making his students use
> it.  No matter how many time I showed him the security holes he
> just insisted I was wrong and that it be available  and wide open.

Maybe he had this crazy idea that programming code
read input, does some processing and write output and that
the main responsibility for correctness, security, performance
and whatever belongs with the person writing the code.

:-)

Arne

In article <udhu9l$jul$1@panix2.panix.com>, kludge@panix.com (Scott
Dorsey) wrote:

> Our IT department back in 2016 went on a binge of getting rid of
> anything that was on the inventory as a "laptop" or "portable
> computer" that could not have the hard drive encrypted.
>
> But most interestingly it meant we got rid of a whole bunch of
> mechanical slide rule devices (E-6B flight computers) because
> they could not be encrypted.

Thanks, you've made me feel better about my IT department. They can be
very annoying, but they are not *that* dumb.

We've had the "all laptops must be encrypted" rule applied, but were able
to negotiate exceptions for ARM Windows laptops, that are used as
build/test machines and are physically locked to their racking. There
weren't any ARM Windows desktops on sale at the time.

We explained that when we've finished with the laptops as build machines,
we'll encrypt them should someone want them as personal devices (which
will not happen). I could feel IT wanting to ask "What if some manager
demands one as a personal device now?" to which the official answer would
have been "We tell them they'd be removing our ability to deliver product
to our fastest-growing customer" and the unofficial answer would be "We
don't employ managers that dumb in the UK."

John

On 9/9/2023 10:05 AM, Scott Dorsey wrote:
> bill <bill.gunshannon@gmail.com> wrote:
>>
>> I had to support it at the University because we had a professor
>> who insisted on teaching it, using it and making his students use
>> it. No matter how many time I showed him the security holes he
>> just insisted I was wrong and that it be available and wide open.
>
> Don't show the professor the security holes. Show them to the students.
> The result is always much more satisfying.

Showing them (I did) doesn't change the requirements for that
particular professors courses. If he insists that they do
something stupid, they have to comply to get through the class.

bill

On 9/9/2023 11:19 AM, Arne Vajhøj wrote:
> On 9/8/2023 6:59 PM, bill wrote:
>> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>>> Unfortunately, I _do_ have to use PHP sometimes.
>>>
>>> It didn't take me long to establish some solid rules, such as strict
>>> comparisons at _all_ times, and to use a monitor library I wrote that
>>> has the allowed error level turned all the way down so that things
>>> which PHP normally allows through generate an error instead.
>>
>> I had to support it at the University because we had a professor
>> who insisted on teaching it, using it and making his students use
>> it.  No matter how many time I showed him the security holes he
>> just insisted I was wrong and that it be available  and wide open.
>
> Maybe he had this crazy idea that programming code
> read input, does some processing and write output and that
> the main responsibility for correctness, security, performance
> and whatever belongs with the person writing the code.
>
> :-)
>
> Arne
>
>

Nice thought, but the particular problem I was fighting was
inherent to PHP and the programmer can only stop it by using
a better tool.

bill

On 9/9/2023 11:45 AM, bill wrote:
> On 9/9/2023 11:19 AM, Arne Vajhøj wrote:
>> On 9/8/2023 6:59 PM, bill wrote:
>>> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>>>> Unfortunately, I _do_ have to use PHP sometimes.
>>>>
>>>> It didn't take me long to establish some solid rules, such as strict
>>>> comparisons at _all_ times, and to use a monitor library I wrote that
>>>> has the allowed error level turned all the way down so that things
>>>> which PHP normally allows through generate an error instead.
>>>
>>> I had to support it at the University because we had a professor
>>> who insisted on teaching it, using it and making his students use
>>> it.  No matter how many time I showed him the security holes he
>>> just insisted I was wrong and that it be available  and wide open.
>>
>> Maybe he had this crazy idea that programming code
>> read input, does some processing and write output and that
>> the main responsibility for correctness, security, performance
>> and whatever belongs with the person writing the code.
>>
>> :-)
>
> Nice thought, but the particular problem I was fighting was
> inherent to PHP and the programmer can only stop it by using
> a better tool.

You are aware that PHP is Turing complete?

Arne

On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
> On 9/9/2023 11:45 AM, bill wrote:
>> On 9/9/2023 11:19 AM, Arne Vajhøj wrote:
>>> On 9/8/2023 6:59 PM, bill wrote:
>>>> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>>>>> Unfortunately, I _do_ have to use PHP sometimes.
>>>>>
>>>>> It didn't take me long to establish some solid rules, such as strict
>>>>> comparisons at _all_ times, and to use a monitor library I wrote that
>>>>> has the allowed error level turned all the way down so that things
>>>>> which PHP normally allows through generate an error instead.
>>>>
>>>> I had to support it at the University because we had a professor
>>>> who insisted on teaching it, using it and making his students use
>>>> it.  No matter how many time I showed him the security holes he
>>>> just insisted I was wrong and that it be available  and wide open.
>>>
>>> Maybe he had this crazy idea that programming code
>>> read input, does some processing and write output and that
>>> the main responsibility for correctness, security, performance
>>> and whatever belongs with the person writing the code.
>>>
>>> :-)
>>
>> Nice thought, but the particular problem I was fighting was
>> inherent to PHP and the programmer can only stop it by using
>> a better tool.
>
> You are aware that PHP is Turing complete?
>

Which means what in the concept of security? It has nothing
to do with the syntax or even the function of the programs
written with it. The problem resides in the PHP interpreter
and the programmer has no control over it. If certain features
are turned on, PHP can be coerced to execute arbitrary commands
on the machine running the web server that is supporting PHP.

Unless someone actually fixed this. I have been out of that game
for almost 10 years now. But I would still never trust PHP.

bill

On 9/9/2023 12:53 PM, bill wrote:
> On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
>> On 9/9/2023 11:45 AM, bill wrote:
>>> On 9/9/2023 11:19 AM, Arne Vajhøj wrote:
>>>> On 9/8/2023 6:59 PM, bill wrote:
>>>>> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>>>>>> Unfortunately, I _do_ have to use PHP sometimes.
>>>>>>
>>>>>> It didn't take me long to establish some solid rules, such as strict
>>>>>> comparisons at _all_ times, and to use a monitor library I wrote that
>>>>>> has the allowed error level turned all the way down so that things
>>>>>> which PHP normally allows through generate an error instead.
>>>>>
>>>>> I had to support it at the University because we had a professor
>>>>> who insisted on teaching it, using it and making his students use
>>>>> it.  No matter how many time I showed him the security holes he
>>>>> just insisted I was wrong and that it be available  and wide open.
>>>>
>>>> Maybe he had this crazy idea that programming code
>>>> read input, does some processing and write output and that
>>>> the main responsibility for correctness, security, performance
>>>> and whatever belongs with the person writing the code.
>>>>
>>>> :-)
>>>
>>> Nice thought, but the particular problem I was fighting was
>>> inherent to PHP and the programmer can only stop it by using
>>> a better tool.
>>
>> You are aware that PHP is Turing complete?
>
> Which means what in the concept of security?  It has nothing
> to do with the syntax or even the function of the programs
> written with it.

It means that you did not have to rewrite in another language to
fix the problem.

>   The problem resides in the PHP interpreter
> and the programmer has no control over it.  If certain features
> are turned on, PHP can be coerced to execute arbitrary commands
> on the machine running the web server that is supporting PHP.

Code and programming languages and not magic that does
something by itself.

The programmer write code to do certain things and may also configure
compiler or interpreter to handle some things a certain way and
then the code does it.

PHP receive input from the user in $_GET, $_POST etc. and the
PHP code can treat that proper or not so proper. PHP has a number
of functions to handle untrusted input.

Arne

On 2023-09-09 19:25, Arne Vajhøj wrote:
> On 9/9/2023 12:53 PM, bill wrote:
>> On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
>>> On 9/9/2023 11:45 AM, bill wrote:
>>>> On 9/9/2023 11:19 AM, Arne Vajhøj wrote:
>>>>> On 9/8/2023 6:59 PM, bill wrote:
>>>>>> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>>>>>>> Unfortunately, I _do_ have to use PHP sometimes.
>>>>>>>
>>>>>>> It didn't take me long to establish some solid rules, such as strict
>>>>>>> comparisons at _all_ times, and to use a monitor library I wrote
>>>>>>> that
>>>>>>> has the allowed error level turned all the way down so that things
>>>>>>> which PHP normally allows through generate an error instead.
>>>>>>
>>>>>> I had to support it at the University because we had a professor
>>>>>> who insisted on teaching it, using it and making his students use
>>>>>> it.  No matter how many time I showed him the security holes he
>>>>>> just insisted I was wrong and that it be available  and wide open.
>>>>>
>>>>> Maybe he had this crazy idea that programming code
>>>>> read input, does some processing and write output and that
>>>>> the main responsibility for correctness, security, performance
>>>>> and whatever belongs with the person writing the code.
>>>>>
>>>>> :-)
>>>>
>>>> Nice thought, but the particular problem I was fighting was
>>>> inherent to PHP and the programmer can only stop it by using
>>>> a better tool.
>>>
>>> You are aware that PHP is Turing complete?
>>
>> Which means what in the concept of security?  It has nothing
>> to do with the syntax or even the function of the programs
>> written with it.
>
> It means that you did not have to rewrite in another language to
> fix the problem.

That definitely does not neccesarily follow.

Consider for example C and some language like BASIC, which have full
control over strings.
Both are turing complete. But if you want to avoid the problem of
strings being handled as pointers to chunks of memory terminated by a
NUL, then you need to move away from C (to for example BASIC).
You cannot "fix" the problem of how C looks at strings.

The turing complete aspect have nothing to do with that.

Johnny

bill <bill.gunshannon@gmail.com> wrote:
>On 9/9/2023 10:05 AM, Scott Dorsey wrote:
>> bill <bill.gunshannon@gmail.com> wrote:
>>>
>>> I had to support it at the University because we had a professor
>>> who insisted on teaching it, using it and making his students use
>>> it. No matter how many time I showed him the security holes he
>>> just insisted I was wrong and that it be available and wide open.
>>
>> Don't show the professor the security holes. Show them to the students.
>> The result is always much more satisfying.
>
>Showing them (I did) doesn't change the requirements for that
>particular professors courses. If he insists that they do
>something stupid, they have to comply to get through the class.

Oh yes. School is all about doing stupid things and then finding out why
they are stupid later on.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 9/9/2023 10:10 AM, Arne Vajhøj wrote:
> On 9/8/2023 2:05 PM, Simon Clubley wrote:
>> Unfortunately, I _do_ have to use PHP sometimes.
>>
>> It didn't take me long to establish some solid rules, such as strict
>> comparisons at _all_ times, and to use a monitor library I wrote that
>> has the allowed error level turned all the way down so that things
>> which PHP normally allows through generate an error instead.
>>
>> |PHP is built to keep chugging along at all costs. When faced with either
>> |doing something nonsensical or aborting with an error, it will do something
>> |nonsensical. Anything is better than nothing.
>>
>> It is a horrible, horrible, language that like Javascript has been
>> turned from something used for writing little scripts into something
>> used to write mission-critical and highly sensitive applications,
>> which neither of them are suitable for.
>>
>> From that page:
>>
>> |PHP is built to keep chugging along at all costs. When faced with either
>> |doing something nonsensical or aborting with an error, it will do something
>> |nonsensical. Anything is better than nothing.
>>
>> That sums up the language perfectly (and the same mindset is equally true
>> for Javascript in IMHO). They were both designed for quick hacks, not for
>> serious mission-critical applications.
>
> PHP actually follows the same rules as most languages:
> not able to continue => error
> able to continue => warning
> error => stop execution
> warning => continue execution
>
> But PHP does allow some constructs that other languages do not.
>
> As an example:
>
> <?php
>
> class C { }
>
> function check($lbl, $v) {
> $vv = $v ? 'true' : 'false';
> echo "$lbl is $vv\r\n";
> }
>
> check('true', true);
> check('false', false);
> check('123', 123);
> check('"ABC"', 'ABC');
> check('0', 0);
> check('""', '');
> check('"0"', '0');
> check('(instance of C)', new C());
> check('null', null);
>
> ?>
>
> outputs:
>
> true is true
> false is false
> 123 is true
> "ABC" is true
> 0 is false
> "" is false
> "0" is false
> (instance of C) is true
> null is false
>
> But languages get designed for certain purposes/contexts/users.

Like ego ?

> PHP was designed to allow people that does not understand
> data types to write code.

Perhaps people who cannot understand something as simple as a data type should
not write code ?

> If people do not understand the difference between boolean
> data type and other data types, then PHP behavior makes sense.

See above ...

> There is little point in criticizing a language for meeting
> its design goals.

But there is great point in criticizing the design and goals.

> The question is whether the language is a good choice for
> a specific context.
>
> I have no idea whether PHP was the right or the wrong choice
> for your web application.
>
> There is a pretty big majority in the IT industry that believe
> type safe languages are not the right choice for web applications.
> Business critical web site or not.

There are quite a few idiots on the planet also.

> Just like you can ask a C compiler to not continue with
> warnings then you can do the same with PHP.
>
> function always_die($errno, $errstr, $errfile, $errline ) {
> echo "$errstr in $errfile on line $errline";
> die();
> }
> set_error_handler('always_die');
>
> will force PHP to stop at warnings and notices (PHP term for
> informationals).
>
> Arne
>
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 9/9/2023 11:33 AM, John Dallman wrote:
> In article <udhu9l$jul$1@panix2.panix.com>, kludge@panix.com (Scott
> Dorsey) wrote:
>
>> Our IT department back in 2016 went on a binge of getting rid of
>> anything that was on the inventory as a "laptop" or "portable
>> computer" that could not have the hard drive encrypted.
>>
>> But most interestingly it meant we got rid of a whole bunch of
>> mechanical slide rule devices (E-6B flight computers) because
>> they could not be encrypted.
>
> Thanks, you've made me feel better about my IT department. They can be
> very annoying, but they are not *that* dumb.
>
> We've had the "all laptops must be encrypted" rule applied, but were able
> to negotiate exceptions for ARM Windows laptops, that are used as
> build/test machines and are physically locked to their racking. There
> weren't any ARM Windows desktops on sale at the time.
>
> We explained that when we've finished with the laptops as build machines,
> we'll encrypt them should someone want them as personal devices (which
> will not happen). I could feel IT wanting to ask "What if some manager
> demands one as a personal device now?" to which the official answer would
> have been "We tell them they'd be removing our ability to deliver product
> to our fastest-growing customer" and the unofficial answer would be "We
> don't employ managers that dumb in the UK."
>
> John
>

It might be interesting to have a contest for people to mention devices, such as
automobiles, calculators, etc that must be gotten rid of?

Nah, forget that, it would result in millions of off topic posts.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 9/9/2023 11:16 AM, Arne Vajhøj wrote:
> PHP does not have many of the common general flaws like
> buffer overflow and memory leak.
>
> PHP got all the features needing for secure web applications.
>
> Some old features that were questionable from a security
> perspective has been removed. Classic example is register_globals
> that been off by default since version 4.2 (21 years ago) and
> was finally removed in version 5.4 (8 years ago).
>
> The most widely used frameworks has added features to make it
> easy to avoid common web security problems. Example: Laravel
> always check for token to prevent CSRF.

And CSRF is a real problem.

On OWASP top ten it made:

2007 - 5th
2010 - 5th
2013 - 8th
2017 - missing
2021 - 10th
2023 API - 7th

Modern web frameworks like PHP Laravel, ASP.NET MVC, RoR,
JSF etc. has builtin anti forgery token support to prevent
CSRF.

Arne

On 9/9/2023 2:44 PM, Johnny Billquist wrote:
> On 2023-09-09 19:25, Arne Vajhøj wrote:
>> On 9/9/2023 12:53 PM, bill wrote:
>>> On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
>>>> On 9/9/2023 11:45 AM, bill wrote:
>>>>> Nice thought, but the particular problem I was fighting was
>>>>> inherent to PHP and the programmer can only stop it by using
>>>>> a better tool.
>>>>
>>>> You are aware that PHP is Turing complete?
>>>
>>> Which means what in the concept of security?  It has nothing
>>> to do with the syntax or even the function of the programs
>>> written with it.
>>
>> It means that you did not have to rewrite in another language to
>> fix the problem.
>
> That definitely does not neccesarily follow.
>
> Consider for example C and some language like BASIC, which have full
> control over strings.
> Both are turing complete. But if you want to avoid the problem of
> strings being handled as pointers to chunks of memory terminated by a
> NUL, then you need to move away from C (to for example BASIC).
> You cannot "fix" the problem of how C looks at strings.
>
> The turing complete aspect have nothing to do with that.

I cannot follow your argument.

Being turing complete means that it can do anything that
the abstract turing machine and any other turing complete
language can do.

It does not mean that something is easy or best practice
or anything else.

I consider C strings a bad design. But I cannot imagine
any problem that could not be solved with C. In most cases
I think there would be better languages that will make it
possible to implement the functionality faster and
with less risk of errors. But it is still possible to
do it in C.

Arne

On 09/09/2023 22:35, Arne Vajhøj wrote:
> On 9/9/2023 11:16 AM, Arne Vajhøj wrote:
>> PHP does not have many of the common general flaws like
>> buffer overflow and memory leak.
>>
>> PHP got all the features needing for secure web applications.
>>
>> Some old features that were questionable from a security
>> perspective has been removed. Classic example is register_globals
>> that been off by default since version 4.2 (21 years ago) and
>> was finally removed in version 5.4 (8 years ago).
>>
>> The most widely used frameworks has added features to make it
>> easy to avoid common web security problems. Example: Laravel
>> always check for token to prevent CSRF.
>
> And CSRF is a real problem.
>
> On OWASP top ten it made:
>
> 2007 - 5th
> 2010 - 5th
> 2013 - 8th
> 2017 - missing
> 2021 - 10th
> 2023 API - 7th
>
> Modern web frameworks like PHP Laravel, ASP.NET MVC, RoR,
> JSF etc. has builtin anti forgery token support to prevent
> CSRF.
>
> Arne
>

CSRF - what is it?

--
Chris

On 2023-09-09 23:44, Arne Vajhøj wrote:
> On 9/9/2023 2:44 PM, Johnny Billquist wrote:
>> On 2023-09-09 19:25, Arne Vajhøj wrote:
>>> On 9/9/2023 12:53 PM, bill wrote:
>>>> On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
>>>>> On 9/9/2023 11:45 AM, bill wrote:
>>>>>> Nice thought, but the particular problem I was fighting was
>>>>>> inherent to PHP and the programmer can only stop it by using
>>>>>> a better tool.
>>>>>
>>>>> You are aware that PHP is Turing complete?
>>>>
>>>> Which means what in the concept of security?  It has nothing
>>>> to do with the syntax or even the function of the programs
>>>> written with it.
>>>
>>> It means that you did not have to rewrite in another language to
>>> fix the problem.
>>
>> That definitely does not neccesarily follow.
>>
>> Consider for example C and some language like BASIC, which have full
>> control over strings.
>> Both are turing complete. But if you want to avoid the problem of
>> strings being handled as pointers to chunks of memory terminated by a
>> NUL, then you need to move away from C (to for example BASIC).
>> You cannot "fix" the problem of how C looks at strings.
>>
>> The turing complete aspect have nothing to do with that.
>
> I cannot follow your argument.
>
> Being turing complete means that it can do anything that
> the abstract turing machine and any other turing complete
> language can do.
>
> It does not mean that something is easy or best practice
> or anything else.
>
> I consider C strings a bad design. But I cannot imagine
> any problem that could not be solved with C. In most cases
> I think there would be better languages that will make it
> possible to implement the functionality faster and
> with less risk of errors. But it is still possible to
> do it in C.

If the problem is something in the construction of the language (which I
believe was the complaint about PHP), then the fact that it is Turing
complete don't make the constructs any better. Just because you can
solve every problem with the language don't mean that all languages are
equal.

If you don't believe in that, then may I suggest you start writing
everything in TECO. After all, it is also Turing Complete.

Johnny

On 9/8/2023 10:03 AM, Dan Cross wrote:
> In article <km0l0iF8emlU3@mid.individual.net>,
> bill <bill.gunshannon@gmail.com> wrote:
>> On 9/7/2023 9:18 AM, Dave Froble wrote:
>>> [snip]
>>> My moment of enlightenment was the day I was told I wasn't a "real
>>> programmer" since I didn't know or use PHP.  Guy didn't even know what
>>> assembly language was.  It's actually a bit scary.
>>>
>>
>> I'm a real programmer. I know PHP and that's why I don't use it.
>
> This seems apropos:
> https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

I think this is a typical example of internet whining.

He doesn't like PHP and have a very long list of "issues".

But it is a very mixed bag of:
- misunderstandings
- so what
- real issues

A few examples.

"Namespaces use \."

Yes. A period is what other languages use. But so what. You use what
the language prescribe.

"The new array syntax results in [key => value], unique among every
language with hash literals."

Scala use:

Map(1 -> "A", 2 -> "BB", 3 -> "CCC")

C# use:

new Dictionary<int, string> { [1] = "A", [2] = "BB", [3] = "CCC" };

Each language is slightly different, but same concept.

"There is no threading support whatsoever. (Not surprising, given the
above.) Combined with the lack of built-in fork (mentioned below), this
makes parallel programming extremely difficult."

PHP is designed to be run by a web-server and the web-server
will do the thread start or fork.

It is generally considered a big no no to have web application
code start threads (or fork).

"In PHP, these functions return false. If you use FALSE as an index, or
do much of anything with it except compare with ===, PHP will silently
convert it to 0 for you. Your program will not blow up; it will,
instead, do the wrong thing with no warning,"

I don't like that either.

But PHP was designed like that a few decades ago and too late to change.

"There is no way to declare a variable. Variables that don’t exist are
created with a null value when first used."

And gives a warning. So if someone configure the script to die at
warning, then it dies when it happens.

Should it have been an error? I think so.

"There’s no such thing as a nested or locally-scoped function or class.
They’re only global."

It is not that unusual for languages to not to allow functions inside
functions.

And even though many of the well-known OO languages support nested
classes, then some of them come with complications that does not
fit well with PHP philosophy.

"Appending to an array is done with $foo[] = $bar."

Other languages use:

a.append(b)

or

a.push(b)

But does it really matter much if is brackets or append or push or
something fourth?

"echo is a statement-y kind of thing, not a function."

Yes. It is like Python 2.x print. And?

"E_STRICT is a thing, but it doesn’t seem to actually prevent much and
there’s no documentation on what it actually does."

It is documented:

https://www.php.net/manual/en/errorfunc.constants.php

"PHP errors and PHP exceptions are completely different beasts. They
don’t seem to interact at all."

The errors are typical stuff that would have been caught during
compilation if it had been a compiled language while exceptions
are runtime conditions.

I am not so convinced that they should be treated identical.

"Closures require explicitly naming every variable to be closed-over.
Why can’t the interpreter figure this out? Kind of hamstrings the whole
feature."

It is unusual, but it actually provides safer and more readable
code, so ...

"“Variadic” functions require faffing about with func_num_args,
func_get_arg, and func_get_args. There’s no syntax for such a thing".

It is messy.

But PHP is not the only language where that stuff is messy.

"Built-in types are not objects"

True. But lot of OO languages got that problem.

"PHP has first-class support for “abstract classes”, which are classes
that cannot be instantiated. Code in similar languages achieves this by
throwing an exception in the constructor."

So PHP chose their OO to be more Java'ish/C#'ish. It is a choice.

"Subclasses cannot override private methods. Subclass overrides of
public methods can’t even see, let alone call, the superclass’s private
methods. Problematic for, say, test mocks."

WTF

That is how private works. If the subclass need access to the methods
they need to be declared protected.

"Methods cannot be named e.g. “list”, because list() is special syntax
(not a function) and the parser gets confused."

Every language has some reserved words. It seems like list is reserved
in PHP.

"Chunks of the library are wildly inconsistent from one another."

Yes. It is a mess.

PHP is very much bazaar.

https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

"Way too many XML packages."

Actually not that different from other large technologies like
Java and .NET. Different needs leads to different solutions.

"Warts like mysql_real_escape_string, even though it has the same
arguments as the broken mysql_escape_string, just because it’s part of
the MySQL C API."

mysql_real_escape_string has 2 arguments - mysql_escape_string only got
1 argument.

"strtok is apparently designed after the equivalent C function, which is
already a bad idea for various reasons."

The bazaar strikes again. Someone liked C strtok and added it
to PHP. Noone vetoed it.

I don't like strtok either. But if you go bazaar then you go bazaar.

"No Unicode support. Only ASCII will work reliably,"

Single byte charsets work fine - not just 7 bit ASCII.

But this is a known problem.

PHP 6.x was supposed to add unicode support. And PHP 6.x was
never released. Hard problem to add unicode support in a
backwards compatible manner.

"Negative indexing doesn’t work,"

That is not unusual.

:-)

"A single shared file, php.ini, controls massive parts of PHP’s
functionality and introduces complex rules regarding what overrides what
and when."

A lot of servers has a single config file for everything running on the
server.

"PHP basically runs as CGI."

No. PHP rarely runs as CGI. Apache module or FastCGI.

"Blank lines before or after the <?php ... ?> tags, even in libraries,
count as literal text"

Of course. That is how template systems that is based on mixing literal
text and code inside markup works.

"PHP is naturally tied to Apache."

No. Apache is probably the most widely PHP server. But nginx and IIS
are also used for PHP. And in the VMS world then both OSU and WASD
can run PHP.

"No CSRF protection. You get to do it yourself."

That comes with the MVC framework used on top of PHP not
with PHP.

"Making this worse is the common cry for “sanitizing your inputs”.
That’s completely wrong; you can’t wave a magic wand to make a chunk of
data inherently “clean”. What you need to do is speak the language: use
placeholders with SQL, use argument lists when spawning processes, etc."

Sanitizing input is something that all good web frameworks do.

"The original built-in MySQL bindings, still widely-used, have no way to
create prepared statements."

The mysql extension was superseded by mysqli in 5.0 (19 years ago) and
removed in 7.0 (8 years ago).

And it was not really a PHP issue. It was a C issue.

The original MySQL C API did not support prepared statement
(parameters).

So obviously the PHP wrapper around it did not either.

When MySQL added support for prepared statement
(parameters) in C then PHP added as well.

"register_globals. It’s been off by default for a while by now,"

21 years is indeed "a while".

Arne

On 9/9/2023 8:16 PM, Johnny Billquist wrote:
> On 2023-09-09 23:44, Arne Vajhøj wrote:
>> On 9/9/2023 2:44 PM, Johnny Billquist wrote:
>>> On 2023-09-09 19:25, Arne Vajhøj wrote:
>>>> On 9/9/2023 12:53 PM, bill wrote:
>>>>> On 9/9/2023 12:14 PM, Arne Vajhøj wrote:
>>>>>> On 9/9/2023 11:45 AM, bill wrote:
>>>>>>> Nice thought, but the particular problem I was fighting was
>>>>>>> inherent to PHP and the programmer can only stop it by using
>>>>>>> a better tool.
>>>>>>
>>>>>> You are aware that PHP is Turing complete?
>>>>>
>>>>> Which means what in the concept of security?  It has nothing
>>>>> to do with the syntax or even the function of the programs
>>>>> written with it.
>>>>
>>>> It means that you did not have to rewrite in another language to
>>>> fix the problem.
>>>
>>> That definitely does not neccesarily follow.
>>>
>>> Consider for example C and some language like BASIC, which have full
>>> control over strings.
>>> Both are turing complete. But if you want to avoid the problem of
>>> strings being handled as pointers to chunks of memory terminated by a
>>> NUL, then you need to move away from C (to for example BASIC).
>>> You cannot "fix" the problem of how C looks at strings.
>>>
>>> The turing complete aspect have nothing to do with that.
>>
>> I cannot follow your argument.
>>
>> Being turing complete means that it can do anything that
>> the abstract turing machine and any other turing complete
>> language can do.
>>
>> It does not mean that something is easy or best practice
>> or anything else.
>>
>> I consider C strings a bad design. But I cannot imagine
>> any problem that could not be solved with C. In most cases
>> I think there would be better languages that will make it
>> possible to implement the functionality faster and
>> with less risk of errors. But it is still possible to
>> do it in C.
>
> If the problem is something in the construction of the language (which I
> believe was the complaint about PHP), then the fact that it is Turing
> complete don't make the constructs any better. Just because you can
> solve every problem with the language don't mean that all languages are
> equal.
>
> If you don't believe in that, then may I suggest you start writing
> everything in TECO. After all, it is also Turing Complete.

I get that.

In fact that was what I wrote in what you replied to.

But my discussion with Bill was not whether it was a good fit to
solve the problem but whether it was possible.

Turing complete indicate possible.

Turing complete does not indicate good fit for solving the
problem.

Millions of web sites running PHP indicate that PHP is a good
fit for solving web security problems.

Arne

On 9/9/2023 7:22 PM, Chris Townley wrote:
> On 09/09/2023 22:35, Arne Vajhøj wrote:
>> On 9/9/2023 11:16 AM, Arne Vajhøj wrote:
>>> PHP does not have many of the common general flaws like
>>> buffer overflow and memory leak.
>>>
>>> PHP got all the features needing for secure web applications.
>>>
>>> Some old features that were questionable from a security
>>> perspective has been removed. Classic example is register_globals
>>> that been off by default since version 4.2 (21 years ago) and
>>> was finally removed in version 5.4 (8 years ago).
>>>
>>> The most widely used frameworks has added features to make it
>>> easy to avoid common web security problems. Example: Laravel
>>> always check for token to prevent CSRF.
>>
>> And CSRF is a real problem.
>>
>> On OWASP top ten it made:
>>
>> 2007 - 5th
>> 2010 - 5th
>> 2013 - 8th
>> 2017 - missing
>> 2021 - 10th
>> 2023 API - 7th
>>
>> Modern web frameworks like PHP Laravel, ASP.NET MVC, RoR,
>> JSF etc. has builtin anti forgery token support to prevent
>> CSRF.
>
> CSRF - what is it?

Cross Site Request Forgery

Simple (slightly oversimplified) example:

* you login to your bank and the bank web server provide
you with a session cookie that your browser use for
all requests in that session
* you need to do a money transfer so you fill out a
form with amount + from account + to account
* that form get submitted to the bank as a POST request
* without closing the browser you go to www.verybadsite.com
* they show you a form with USD amount and expecting them
to show equivalent GBP amount
* but the form has 3 invisible fields: amount +
from account + to account filled out with an amount +
your account + their account and the POST URL is the banks
* when you hit submit the transfer goes to the bank
and your super friendly browser send the cookie
with the request and the super friendly bank web server
has kept the session valid

https://en.wikipedia.org/wiki/Cross-site_request_forgery

Arne

On 9/9/2023 9:06 PM, Arne Vajhøj wrote:
> On 9/9/2023 7:22 PM, Chris Townley wrote:
>> CSRF - what is it?
>
> Cross Site Request Forgery
>
> Simple (slightly oversimplified) example:
>
> * you login to your bank and the bank web server provide
>   you with a session cookie that your browser use for
>   all requests in that session
> * you need to do a money transfer so you fill out a
>   form with amount + from account + to account
> * that form get submitted to the bank as a POST request
> * without closing the browser you go to www.verybadsite.com
> * they show you a form with USD amount and expecting them
>   to show equivalent GBP amount
> * but the form has 3 invisible fields: amount +
>   from account + to account filled out with an amount +
>   your account + their account and the POST URL is the banks
> * when you hit submit the transfer goes to the bank
>   and your super friendly browser send the cookie
>   with the request and the super friendly bank web server
>   has kept the session valid
>
> https://en.wikipedia.org/wiki/Cross-site_request_forgery

One of the tools used to prevent it is a anti forgery token.

Basically when the bank provide you with the form then
it also generates a hidden field with a huge cryptographic
secure number and saves the same number in the session.
The the code processing the POST request checks if the
submitted token matches the token in the session.

The bad guys cannot guess the token. And the bank should
remove the token from session as soon as the POST request
is received so it can only be used once (which has the
positive side effect of also preventing double submits!!).

Arne