Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #56257 > unrolled thread

can forth outdo java? for web and everything?

Back to article view | Back to comp.lang.forth

Contents

  can forth outdo java? for web and everything? gavino himself <jackvanc3@gmail.com> - 2017-03-24 21:22 -0700
    Re: can forth outdo java? for web and everything? Helmar Wodtke <helmwo@gmail.com> - 2017-03-25 08:12 -0700
    Re: can forth outdo java? for web and everything? Ron Aaron <rambamist@gmail.com> - 2017-03-25 20:00 +0300
      Re: can forth outdo java? for web and everything? Cecil Bayona <cbayona@cbayona.com> - 2017-03-25 12:04 -0500
        Re: can forth outdo java? for web and everything? Ron Aaron <rambamist@gmail.com> - 2017-03-25 21:08 +0300
        Re: can forth outdo java? for web and everything? "Elizabeth D. Rather" <erather@forth.com> - 2017-03-25 11:41 -1000
          Re: can forth outdo java? for web and everything? Ron Aaron <rambamist@gmail.com> - 2017-03-26 06:53 +0300
            Re: can forth outdo java? for web and everything? "Elizabeth D. Rather" <erather@forth.com> - 2017-03-25 18:13 -1000
              Security (was Re: can forth outdo java? for web and everything?) Ron Aaron <rambamist@gmail.com> - 2017-03-26 07:47 +0300
              Re: can forth outdo java? for web and everything? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-26 15:24 +0000
    Re: can forth outdo java? for web and everything? hughaguilar96@gmail.com - 2017-03-25 12:53 -0700
    Re: can forth outdo java? for web and everything? jean-pierre@buechi-schmitt.ch - 2017-03-26 02:01 -0700
    Re: can forth outdo java? for web and everything? gavino himself <jackvanc3@gmail.com> - 2017-03-29 21:43 -0700

#56257 — can forth outdo java? for web and everything?

seems better

anyone outdoing java now with forth?

[toc] | [next] | [standalone]

#56278

Am Samstag, 25. März 2017 05:22:58 UTC+1 schrieb gavino himself:
> seems better
> 
> anyone outdoing java now with forth?

You are comparing a rock solid stone with a shovel of mud. Depends on you, what you want to build cathedrals of. A stone cathedral is stone by stone. Mud has everything you need to build inside - if you let it dry it might be solid. Usually you have to burn it (not following development of the interfaces or versions) and it will be like stone. What do you think is Java? Rock solid stone or a shovel of mud?

-Helmar

[toc] | [prev] | [next] | [standalone]

#56280

On 25/03/2017 7:22, gavino himself wrote:
> seems better

than what?

> anyone outdoing java now with forth?

yes, every day.

[toc] | [prev] | [next] | [standalone]

#56281

On 3/25/2017 12:00 PM, Ron Aaron wrote:
>
>
> On 25/03/2017 7:22, gavino himself wrote:
>> seems better
>
> than what?
>
>> anyone outdoing java now with forth?
>
> yes, every day.
>
Java is such a complicated mess and it's supposed advantage in security 
is a myth.

Quite a few libraries with hundreds of entries to master.

On the other hand Forth is simple but and a huge but there is no 
security to speak of.

-- 
Cecil - k5nwa

[toc] | [prev] | [next] | [standalone]

#56285

On 25/03/2017 20:04, Cecil Bayona wrote:
> On 3/25/2017 12:00 PM, Ron Aaron wrote:
>>
>>
>> On 25/03/2017 7:22, gavino himself wrote:
>>> seems better
>>
>> than what?
>>
>>> anyone outdoing java now with forth?
>>
>> yes, every day.
>>
> Java is such a complicated mess and it's supposed advantage in security
> is a myth.
> 
> Quite a few libraries with hundreds of entries to master.
> 
> On the other hand Forth is simple but and a huge but there is no
> security to speak of.

8th does have a number of security-related features built-in.  But it's
not as low-level as traditional Forths are

[toc] | [prev] | [next] | [standalone]

#56299

On 3/25/17 7:04 AM, Cecil Bayona wrote:
> On 3/25/2017 12:00 PM, Ron Aaron wrote:
>>
>>
>> On 25/03/2017 7:22, gavino himself wrote:
>>> seems better
>>
>> than what?
>>
>>> anyone outdoing java now with forth?
>>
>> yes, every day.
>>
> Java is such a complicated mess and it's supposed advantage in security
> is a myth.
>
> Quite a few libraries with hundreds of entries to master.
>
> On the other hand Forth is simple but and a huge but there is no
> security to speak of.

Security is best defined and pursued in the context of an application. 
Forth applications can be extremely secure, such as the payment terminal 
applications FORTH, Inc. and MPE developed for Europay in the late 90's. 
FORTH, Inc. has done a great deal of work for some government agencies 
which are extremely security conscious, and if they had ever been 
breached I'm sure we'd have been called on it at once.

Cheers,
Elizabbeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#56313

On 26/03/2017 0:41, Elizabeth D. Rather wrote:
> On 3/25/17 7:04 AM, Cecil Bayona wrote:

>> Java is such a complicated mess and it's supposed advantage in security
>> is a myth.
>>
>> Quite a few libraries with hundreds of entries to master.
>>
>> On the other hand Forth is simple but and a huge but there is no
>> security to speak of.
> 
> Security is best defined and pursued in the context of an application.
> Forth applications can be extremely secure...

Well, yes.  Any application in any language "can be" extremely secure.
But there are standard approaches which minimize the attack-surface.

For example: eliminating buffer overflows.  A substantial number of
hacks "in the wild" are due to forced buffer overflows.  Or for example,
accessing arbitrary memory addresses.

C (the majority implementation language for many years) and its ilk to
virtually nothing to help prevent such attacks.  Rather, the programmer
is cautioned to use X function rather than Y function, and is given an
entire litany of does and don'ts.

Forth is somewhat better, since strings (for instance) are addr,length
pairs (in most instances).  However, there's no way to know (other than
comments and perhaps naming conventions) whether an item is a buffer or
not, or whether it is 8 bytes or 8000 bytes long.

Higher-level languages generally prevent direct access to memory, and
enforce bounds-checking of access to buffers, specifically to prevent
such problems (and to make the programmer's life easier).

As an example, 8th does not allow direct memory access by de-referencing
an arbitrary number, while both C and Forth do (it's  easier to do so in
Forth, in fact).  So while that ability is sometimes needed in very
low-level code (drivers, etc), it is (almost?) never required in a
user-level application.  That latent ability is an Achilles Heel.

[toc] | [prev] | [next] | [standalone]

#56316

On 3/25/17 5:53 PM, Ron Aaron wrote:
>
>
> On 26/03/2017 0:41, Elizabeth D. Rather wrote:
>> On 3/25/17 7:04 AM, Cecil Bayona wrote:
>
>>> Java is such a complicated mess and it's supposed advantage in security
>>> is a myth.
>>>
>>> Quite a few libraries with hundreds of entries to master.
>>>
>>> On the other hand Forth is simple but and a huge but there is no
>>> security to speak of.
>>
>> Security is best defined and pursued in the context of an application.
>> Forth applications can be extremely secure...
>
> Well, yes.  Any application in any language "can be" extremely secure.
> But there are standard approaches which minimize the attack-surface.
>
> For example: eliminating buffer overflows.  A substantial number of
> hacks "in the wild" are due to forced buffer overflows.  Or for example,
> accessing arbitrary memory addresses.
>
> C (the majority implementation language for many years) and its ilk to
> virtually nothing to help prevent such attacks.  Rather, the programmer
> is cautioned to use X function rather than Y function, and is given an
> entire litany of does and don'ts.

Isn't that more of a C vulnerability? How would a buffer overflow lead 
to a hack in Forth, particularly in a system with segregated code and 
data spaces?

> Forth is somewhat better, since strings (for instance) are addr,length
> pairs (in most instances).  However, there's no way to know (other than
> comments and perhaps naming conventions) whether an item is a buffer or
> not, or whether it is 8 bytes or 8000 bytes long.
>
> Higher-level languages generally prevent direct access to memory, and
> enforce bounds-checking of access to buffers, specifically to prevent
> such problems (and to make the programmer's life easier).

Most FORTH, Inc. applications nowadays are cross-compiled and running in 
microcontrollers, where we have segregated code and data space, and code 
space is usually in flash or rom for systems in the field. And, of 
course, comments and visible names are normally not available in 
cross-compiled apps.

> As an example, 8th does not allow direct memory access by de-referencing
> an arbitrary number, while both C and Forth do (it's  easier to do so in
> Forth, in fact).  So while that ability is sometimes needed in very
> low-level code (drivers, etc), it is (almost?) never required in a
> user-level application.  That latent ability is an Achilles Heel.

It's really poor programming practice anyway, except during debbugging.

Cheers,
Elizabeth

-- 
Elizabeth R. Conklin
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

[toc] | [prev] | [next] | [standalone]

#56317 — Security (was Re: can forth outdo java? for web and everything?)

On 03/26/17 07:13, Elizabeth D. Rather wrote:
> On 3/25/17 5:53 PM, Ron Aaron wrote:

>> C (the majority implementation language for many years) and its ilk to
>> virtually nothing to help prevent such attacks.  Rather, the programmer
>> is cautioned to use X function rather than Y function, and is given an
>> entire litany of does and don'ts.
> 
> Isn't that more of a C vulnerability? How would a buffer overflow lead
> to a hack in Forth, particularly in a system with segregated code and
> data spaces?

Read up on stack-smashing and buffer-overflow attacks.  You'll be
surprised at how vulnerable systems can be.

C applications almost always have segregated code and data spaces, so
that's neither here nor there.
...

>> As an example, 8th does not allow direct memory access by de-referencing
>> an arbitrary number, while both C and Forth do (it's  easier to do so in
>> Forth, in fact).  So while that ability is sometimes needed in very
>> low-level code (drivers, etc), it is (almost?) never required in a
>> user-level application.  That latent ability is an Achilles Heel.
> 
> It's really poor programming practice anyway, except during debbugging.

That's true, but besides the point.  The point is that systems which
make it (easily) possible to have security problems, will indeed have
security problems.  This is nothing new or surprising (or shouldn't be).

[toc] | [prev] | [next] | [standalone]

#56343

"Elizabeth D. Rather" <erather@forth.com> writes:
> How would a buffer overflow lead 
>to a hack in Forth, particularly in a system with segregated code and 
>data spaces?

See the slide titled "Separate return stack: does it protect?" in 

http://www.complang.tuwien.ac.at/anton/euroforth/ef16/papers/ertl-secure.pdf

If you need the accompanying explanations, watch

https://wiki.forth-ev.de/lib/exe/fetch.php/events:security.mp4

Makes me wonder how you determine the security of your applications.
If it's just a checklist consisting of "Is it written in C?" and "Is
code and data space segregated?", that's far from sufficient.

>Most FORTH, Inc. applications nowadays are cross-compiled and running in 
>microcontrollers, where we have segregated code and data space, and code 
>space is usually in flash or rom for systems in the field. And, of 
>course, comments and visible names are normally not available in 
>cross-compiled apps.

None of that is a protection against attacks.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#56290

On Friday, March 24, 2017 at 9:22:58 PM UTC-7, gavino himself wrote:
> seems better
> 
> anyone outdoing java now with forth?

Forth can easily outdo Java in the volume of idiotic forum posts that it generates.

BTW: the English language is somewhat ambiguous. Does "idiotic forum posts" mean posts on an idiotic forum, or idiotic posts on a forum? Of course, from a practical standpoint, this doesn't matter.

[toc] | [prev] | [next] | [standalone]

#56331

Le samedi 25 mars 2017 05:22:58 UTC+1, gavino himself a écrit :
> seems better
> 
> anyone outdoing java now with forth?
Hello,
I work with SwiftForth which is very well done it must be said.
I added a vocabulary to manage databases. Access to a database is completely secure and you can not overflow. All data coming from the net are stored in a database reserved for this purpose. They can be "Osculated" to detect an attack by a Hacker.
This database serves as an interface between the Local computer and the outside world.
It should also be said that Java is a very, very, very bad copy of a Forth system in which one tried to introduce a syntax to the Cpp.
cordially
Louis Jean-Pierre Schmitt

[toc] | [prev] | [next] | [standalone]

#56476

I see astounding amounts of crap being used in modern linux shops:
centos
aws
jvm
cassandra
mongodb
tomcat
jboss
balanceNG
mysql
angular.js
netapp
spark
rabbitMQ
docker
chef
vagrant

jsut megatons of GUNK

I really wonder if you attacked the problem with for you probably could use 1 language and get to 1% the code
maybe less
and be better for it
forth would have to have 100 machine coordinate and have 1 data store that consistent tho
can it?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web