Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #30977 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2014-05-29 21:35 -0400 |
| Last post | 2014-07-17 16:09 -0400 |
| Articles | 20 on this page of 190 — 24 participants |
Back to article view | Back to comp.lang.forth
MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 21:35 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:09 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 19:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:25 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:23 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 22:15 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 13:51 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:08 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:22 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 21:41 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 13:28 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 17:55 -0400
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 16:29 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 14:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 18:07 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 17:24 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:10 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-02 10:57 +0000
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 13:34 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 20:10 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-29 20:29 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:02 -0700
Re: MSP430-Stamp "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-30 04:05 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-05-30 15:13 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 19:57 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-29 23:32 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-29 21:07 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 02:39 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-17 12:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:08 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 00:06 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-07-18 08:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-18 23:42 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 18:28 -0400
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 01:41 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-18 19:48 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-07-18 16:59 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-07-19 14:30 +0200
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-07-19 08:23 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-07-21 10:42 +0200
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:03 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:47 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 11:36 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 09:34 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 10:09 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-31 10:52 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 01:28 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:41 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 02:00 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 23:07 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 03:13 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 07:15 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:33 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 09:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 13:10 -0400
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 18:38 +0200
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:40 -0700
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 11:13 +0200
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-01 09:50 +0000
Re: MSP430-Stamp HaveANiceDay <HaveANiceDay@NoSpam.invalid> - 2014-06-01 12:47 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 12:39 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 10:00 -0700
Re: MSP430-Stamp babruehl@gmail.com - 2014-06-01 11:45 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 14:57 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-01 12:01 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-01 15:12 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-30 03:12 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-30 14:02 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 03:33 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 07:19 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-05-31 12:01 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 09:15 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 13:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-05-31 14:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 14:51 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-05-31 16:22 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 01:33 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 17:31 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:48 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-05-31 19:12 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 22:25 -0700
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-06-01 09:45 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-01 04:16 -0700
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-01 08:51 -1000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-05-31 21:03 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-01 21:17 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-04 22:46 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 13:27 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 08:39 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 16:10 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:10 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-05 19:52 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:25 +0200
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:02 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:56 +0000
Correct Software and Specifications (was Re: MSP430-Stamp) Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-09 09:59 +0100
Re: MSP430-Stamp mhx@iae.nl - 2014-06-05 14:30 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 10:59 +0000
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 15:57 +0200
Formal specifications etc. (was: MSP430-Stamp) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 15:34 +0000
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:48 -0700
Re: Formal specifications etc. anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-05 19:46 +0000
Re: Formal specifications etc. (was: MSP430-Stamp) Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-05 23:02 +0200
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 14:15 -0700
Re: Formal specifications etc. rickman <gnuarm@gmail.com> - 2014-06-05 17:33 -0400
Re: Formal specifications etc. Paul Rubin <no.email@nospam.invalid> - 2014-06-05 15:32 -0700
Re: Formal specifications etc. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-06 04:00 -0500
Re: Formal specifications etc. (was: MSP430-Stamp) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-06 11:05 +0000
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-05 11:01 -0700
Re: MSP430-Stamp Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-06 01:09 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-05 22:01 -0400
Re: MSP430-Stamp stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-31 16:47 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-05-30 12:11 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 12:54 +0200
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-02 11:39 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-02 12:15 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 10:26 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 12:18 -0400
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-02 10:04 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-03 11:51 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:33 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-06 13:02 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 17:31 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-06 16:30 -1000
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 22:52 -0400
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-07 11:58 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 11:40 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-07 20:01 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:05 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-08 22:28 -0400
Re: MSP430-Stamp Gary Bergstrom <forthprgrmr@gmail.com> - 2014-06-08 20:36 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 21:38 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 14:36 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 02:45 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:18 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 15:57 -0400
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-08 16:20 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 20:42 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:05 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:43 +0000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 21:28 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-03 22:43 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 23:31 -0700
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-04 04:13 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:41 -0700
Re: MSP430-Stamp Paul Rubin <no.email@nospam.invalid> - 2014-06-03 01:51 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-03 16:19 +0100
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 09:14 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-03 13:19 -0400
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-03 07:43 -1000
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-03 20:56 -0700
Re: MSP430-Stamp albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-04 10:51 +0000
Re: MSP430-Stamp VisualForth <babruehl@gmail.com> - 2014-06-04 04:06 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-06 21:26 -0400
Re: MSP430-Stamp "VisualForth.com" <babruehl@gmail.com> - 2014-06-06 20:40 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 03:18 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-07 04:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-07 12:01 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:47 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-09 09:28 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:35 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:43 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 15:52 -0700
Re: MSP430-Stamp Coos Haak <chforth@hccnet.nl> - 2014-06-12 02:06 +0200
Re: MSP430-Stamp "Elizabeth D. Rather" <erather@forth.com> - 2014-06-11 15:13 -1000
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:16 -0700
Re: MSP430-Stamp Mikael Nordman <oh2aun@gmail.com> - 2014-06-11 12:56 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-09 16:46 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-09 03:49 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-09 09:47 -0700
Re: MSP430-Stamp Rikard Lang <rikard.lang@gmail.com> - 2014-06-09 23:16 +0200
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-10 07:48 -0700
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:23 -0700
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-11 18:00 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 02:14 -0400
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-12 02:13 -0700
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 13:04 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-12 18:06 -0500
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-12 19:29 -0400
Re: MSP430-Stamp David Schultz <abuse@127.0.0.1> - 2014-06-13 18:48 -0500
Re: MSP430-Stamp Mark Wills <markwills1970@gmail.com> - 2014-06-11 07:26 -0700
Re: MSP430-Stamp visualforth@rocketmail.com - 2014-06-11 10:45 -0700
Re: MSP430-Stamp JUERGEN <epldfpga@aol.com> - 2014-06-13 00:03 -0700
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 11:11 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-06-18 05:27 -0400
Re: MSP430-Stamp Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-06-18 12:29 +0200
Re: MSP430-Stamp rickman <gnuarm@gmail.com> - 2014-07-17 16:09 -0400
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-31 17:31 -1000 |
| Message-ID | <_7KdnWi9fpsLAxfOnZ2dnUVZ_smdnZ2d@supernews.com> |
| In reply to | #31103 |
On 5/31/14 1:33 PM, Bernd Paysan wrote: > Paul Rubin wrote: >> I'm not convinced that it's easy to do in Forth either, if the software >> has much complexity. Look at the OpenSSL Heartbleed bug, for example. >> Do you think that would have been more easily detected in Forth? It >> wasn't a terribly deep or devious bug, but a good programmer made it and >> another good programmer familiar with the codebase missed it on review. > > The amount of bugs in a reviewed and "debugged" code-base is roughly the > same per kLoC; the difference between a good one (like the Linux kernel) and > a bad one isn't that high. > > OpenSSL is a big heap of code. It's simply too large to be trustworthy. > The LibreSSL is going to throw out vast amounts of stuff that is > unnecessary, like portability to OpenVMS and things like that. That alone > will remove quite a number of bugs. > > However, if you do such things in Forth, and you do them right, you'll end > up with much smaller code, and therefore, there will be an awful lot less > bugs in the debugged product. This is just because Forth is way more > expressive, as you write DSLs as you go. The OTA system, since it was designed for smart card terminals, had to do most of the standard crypto functions. They were all coded in Forth (with some of the lowest-level algorithms very meticulously hand-coded by Greg Bailey, who is a considerable crypto expert). They ran on all our targets, even the 8051s. > You can still write bad and bloated Forth programs, of course. But > >> The strength of Forth seems rest to partly in a philosophy of keeping >> the code very simple. There are some applications that can't help being >> complex, and Forth tends to not be used in them. > I think that's more for management reasons than technical ones. Management tends to feel safer using an existing body of code than developing and validating a new one, even if the latter might be smaller, faster, and more secure. ... > > If a Forth programmer gets into a field where people think there is inherent > complexity, they usually don't take much existing stuff, and start with the > biggest source of bugs and bloatware: the specification (this needs to be > burned and the ashes blown into the wind). If you have a big clusterfuck > like Internet crypto, which was being subverted by NSA and other agencies > (the BND e.g. is a very close cooperation partner, as well as the GCHQ) from > day one, you not only have to throw the baby out with the bathwater (it has > been conceived by the devil himself), you also have to demolish the entire > building around the bath, and the stinking sewerage under the city. It's > really *that* bad. > > The heartbleed bug is possible with Forth, too. The question is: Would a > Forth programmer write such a protocol extension that only makes sense in an > UDP-based protocol while SSL is TCP-based? Quite likely not. The other > question is: How much would a Forth programmer have tested? When Heardbleed > was discovered, I wrote a small Forth program to check servers for it; I did > so because all the programs on the Internet checking for Heartbleed are big > bloatware. All you need to check for Heartbleed is to send two fixed SSL > protocol packets via TCP, you don't need a full SSL stack or anything > remotely like that. And the first thing I found was that Heartbleed was > limiting the output to 16k, at a time where everybody else said, Heartbleed > could leak up to 64k of memory. They had read the source code, but they > haven't even tested their assumptions! Before Greg Bailey put his own projects on hold to join Greenarrays, he was supporting a number of clients with vast internet databases. He fully supported SMTP and FTP, though not HTML. His clients had thousands of users sharing his databases, and he said they never had a security breach in the time (>20 years) I was tracking it. I would assume his systems still operating though not being actively extended, although I don't know for sure. > That sort of stuff happens all the time with programming languages where > tinkiering with things isn't easy. You make an unfounded assumption and you > don't find the time to prove it. You don't really debug for anything more > than mere functionality, and that's certainly *not* enough for security > relevant stuff. You must try everything to break your code, and if that > fails, it's good. This is the reason why that sort of stuff happens so > often with other programming languages. In Forth, debugging is fun, and > quick. > Yes. But it is also much easier to do detailed validation on a Forth system. Ask Greg or others who are using Forth in highly secure projects. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 21:48 -0700 |
| Message-ID | <7x7g51xmix.fsf@ruckus.brouhaha.com> |
| In reply to | #31105 |
"Elizabeth D. Rather" <erather@forth.com> writes: > The OTA system, since it was designed for smart card terminals, had to > do most of the standard crypto functions. I'm still trying to get a copy of the spec, but I saw the table of contents, and OTA is nowhere near as complicated as a serious TLS implementation. > They were all coded in Forth (with some of the lowest-level algorithms > very meticulously hand-coded by Greg Bailey, who is a considerable > crypto expert). They ran on all our targets, even the 8051s. I'd be interested in seeing the code, but that doesn't sound likely to happen. > Yes. But it is also much easier to do detailed validation on a Forth > system. Ask Greg or others who are using Forth in highly secure > projects. Greag doesn't sound willing to release the OTA code, so there is no way to check the claims (not saying he's wrong, just that public verification is impossible). Net2o is of more interest because the code is online, but its task is a lot simpler than OpenSSL's (again an example of the Forth philosophy of keeping things simple, in this case by abandoning compatibility with the existing stuff).
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-05-31 19:12 -1000 |
| Message-ID | <Y8KdnVoTUbLIKxfOnZ2dnUVZ_qWdnZ2d@supernews.com> |
| In reply to | #31110 |
On 5/31/14 6:48 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: ... > >> Yes. But it is also much easier to do detailed validation on a Forth >> system. Ask Greg or others who are using Forth in highly secure >> projects. > > Greag doesn't sound willing to release the OTA code, so there is no way > to check the claims (not saying he's wrong, just that public > verification is impossible). Net2o is of more interest because the code > is online, but its task is a lot simpler than OpenSSL's (again an > example of the Forth philosophy of keeping things simple, in this case > by abandoning compatibility with the existing stuff). Greg doesn't have rights to the OTA code, so it's not up to him to release or not. It was pretty exhaustively tested by Mastercard Europe. Greg has also worked on some government-related security projects. He is by far the most knowledgeable and experienced re Forth in this area. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 22:25 -0700 |
| Message-ID | <7xoaydkxpg.fsf@ruckus.brouhaha.com> |
| In reply to | #31111 |
"Elizabeth D. Rather" <erather@forth.com> writes: > Greg doesn't have rights to the OTA code, so it's not up to him to OK, quite understandable, yet there are still no inspectable implementations out there, so "Open" Terminal Architecture is kind of a misnomer. Even the OTA spec isn't available except by coughing up 300 bucks(?) for a copy of the standard. People keep saying it lost to Javacard because of Java superior evil marketing. In fact the specs for Java and Javacard can be downloaded by anyone so of course there's lots more implementations. That doesn't seem evil to me.
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2014-06-01 09:45 +0000 |
| Message-ID | <538af4f6.339585035@news.demon.co.uk> |
| In reply to | #31110 |
On Sat, 31 May 2014 21:48:54 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Greag doesn't sound willing to release the OTA code, so there is no way >to check the claims (not saying he's wrong, just that public >verification is impossible). Just get over it. OTA was funded by Europay and belongs to the successors of Europay, presumably Mastercard. Their legal department is much bigger than ours. I'm sure that both MPE and Forth Inc could find their respective OTA source code if encouraged to, but publishing it for free is currently risk rather than encouragement. The basic OTA token specification started from the specification for SENDIT issued by MPE in the 1990s. There is a significant number of tokenised Forth systems of various degrees of complexity. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-01 04:16 -0700 |
| Message-ID | <7xbnucubfu.fsf@ruckus.brouhaha.com> |
| In reply to | #31122 |
stephenXXX@mpeforth.com (Stephen Pelc) writes: > The basic OTA token specification started from the specification > for SENDIT issued by MPE in the 1990s. There is a significant > number of tokenised Forth systems of various degrees of > complexity. Is the SENDIT spec available? I spent a few minutes looking for it too. Some European and Australian libraries seem to have the OTA spec but it looks like no US libraries have it. Yes that's understandable about Greg not being able to distribute the implementation he wrote. Still it's unfortunate that there are no free implementations out there, and that seems like a basic error on Europay's part, if they were trying to compete with Java.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-01 08:51 -1000 |
| Message-ID | <wc2dncLX5KLX6xbOnZ2dnUVZ_hudnZ2d@supernews.com> |
| In reply to | #31128 |
On 6/1/14 1:16 AM, Paul Rubin wrote: > stephenXXX@mpeforth.com (Stephen Pelc) writes: >> The basic OTA token specification started from the specification >> for SENDIT issued by MPE in the 1990s. There is a significant >> number of tokenised Forth systems of various degrees of >> complexity. > > Is the SENDIT spec available? I spent a few minutes looking for it too. > Some European and Australian libraries seem to have the OTA spec but it > looks like no US libraries have it. > > Yes that's understandable about Greg not being able to distribute the > implementation he wrote. Still it's unfortunate that there are no free > implementations out there, and that seems like a basic error on > Europay's part, if they were trying to compete with Java. They *were* trying to compete with Java in the late 90's, but gave up. Now I think they just don't want to have to respond to requests for info and/or support. Too bad, it was a technological success. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-05-31 21:03 -0700 |
| Message-ID | <7x4n05gtt7.fsf@ruckus.brouhaha.com> |
| In reply to | #31103 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >> OpenSSL Heartbleed bug, for example... > The amount of bugs in a reviewed and "debugged" code-base is roughly the > same per kLoC; the difference between a good one (like the Linux kernel) and > a bad one isn't that high. What? No I don't believe that--for example TeX has had very few bugs reported in its entire history, while Linux has had hundreds. And only code written in unsafe languages like C or Forth can have bugs with consequences like Heartbleed. If OpenSSL were written in Java (to pick an obnoxious example on purpose, as I hate Java) then the Heartbleed bug (out of range subscript) might have made it into the codebase and even been deployed, but triggering it would have resulted in a runtime exception, nothing like key exposure. > OpenSSL is a big heap of code. ... The LibreSSL is going to throw out > vast amounts of stuff Sure, that will help, but throwing out half the code reduces the exposure by just 2x. It won't surprise me if there's two or more awful bugs still undetected in OpenSSL. Therefore eliminating half of the code probably still leaves at least one such bug. > However, if you do such things in Forth, and you do them right, you'll end > up with much smaller code, and therefore, there will be an awful lot less > bugs in the debugged product. This is just because Forth is way more > expressive, as you write DSLs as you go. Meh, that's possible to some extent in most any language, but it takes a lot of careful refactoring even in Forth, and people usually want to just slam out code. > The inherent complexity in SSL (which is horrible and therefore not even an > option to considder if you think about why crypto is circumvented so often) > is much, much lower than OpenSSL, I would guess at a few kLoCs. OpenSSL is > a few hundred kLoCs, and I expect the LibreSSL people to strip it down below > 100kLoCs. I don't know of any full featured SSL implementation as small as a few KLOC (I've hacked inside the limited Python one and the fancier Haskell one and a chunk forked from the Go one, and I've looked at the Java and Erlang ones) and don't forget that a lot of that OpenSSL amount is stuff like off-line certificate management tools. Even the online part has a lot of code devoted to interoperating with other implementations that are even more messed up than OpenSSL itself. > This is then still two orders of magnitude more than net2o. In the real world you have to interoperate with the stuff that's out there. Otherwise we'd all throw out existing natural languages and all speak Esperanto or something. SSL is complicated and crufty and is a feature/misfeature of the reality that is out there and can't be ignored. > And net2o doesn't just replace OpenSSL, it also replaces DNSSEC, and > is going to replace PGP as well. It's certainly true that those things could be replaced with smaller programs. Whether net2o can do all that and stay in the low-kloc range remains to be seen, as well as whether it gets traction. It will be great if it does of course. Don't forgot the requirement that it perform comparably to OpenSSL, since people really do care about that. > The heartbleed bug is possible with Forth, too. The question is: > Would a Forth programmer write such a protocol extension that only > makes sense in an UDP-based protocol while SSL is TCP-based? Quite > likely not. It was for DTLS which is UDP-based, i.e. DTLS extended SSL to handle both TCP and UDP. I don't see that as having been inherently misguided at first glance, though obviously it hit a bad implementation snag. > That sort of stuff happens all the time with programming languages > where tinkiering with things isn't easy. You make an unfounded > assumption and you don't find the time to prove it. You don't really > debug for anything more than mere functionality, and that's certainly > *not* enough for security relevant stuff. You must try everything to > break your code, and if that fails, it's good. This is the reason why > that sort of stuff happens so often with other programming languages. > In Forth, debugging is fun, and quick. I don't find tinkering or debugging in Forth to be especially easier than in Python, Lisp, or Erlang; and in those languages it's still quite easy for bugs to get through. The bugs of course usually manifest as non-catastrophic runtime exceptions, a big improvement over what happens in C. The Haskell QuickCheck tool (basically an automatic fuzz tester) has been ported to Erlang and people who have used it report good results, compared to ad hoc interactive testing. The thing is, with big programs, it's easy to make a small local change that passes very thorough local testing, but ends up breaking something in a remote part of the program. So you need extensive static checks (enforced encapsulation counts as a form of static check) and/or large automatic test suites that exercise all of the code.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-06-01 21:17 +0200 |
| Message-ID | <lmfu8n$95f$1@online.de> |
| In reply to | #31107 |
Paul Rubin wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>> OpenSSL Heartbleed bug, for example... >> The amount of bugs in a reviewed and "debugged" code-base is roughly the >> same per kLoC; the difference between a good one (like the Linux kernel) >> and a bad one isn't that high. > > What? No I don't believe that--for example TeX has had very few bugs > reported in its entire history, while Linux has had hundreds. TeX is an awfully small program by modern standards. "TeX the program" is a book with a few hundred pages, of which a considerable amount are comments, not the actual code. It is just several thousand LoCs. Linux has more than 10 million LoCs. You would expect it to have three orders of magnitude more bugs than TeX. And indeed, it does. The big pile of LaTeX extensions have a lot more bugs than TeX, the program. > And only > code written in unsafe languages like C or Forth can have bugs with > consequences like Heartbleed. If OpenSSL were written in Java (to pick > an obnoxious example on purpose, as I hate Java) then the Heartbleed bug > (out of range subscript) might have made it into the codebase and even > been deployed, but triggering it would have resulted in a runtime > exception, nothing like key exposure. People have analyzed security relevant programs in different programming languages, and the number of security problems per amount of code was about equal. Java Programmers make different mistakes. >> OpenSSL is a big heap of code. ... The LibreSSL is going to throw out >> vast amounts of stuff > > Sure, that will help, but throwing out half the code reduces the > exposure by just 2x. It won't surprise me if there's two or more awful > bugs still undetected in OpenSSL. Therefore eliminating half of the > code probably still leaves at least one such bug. Yes, it still is way too big... I hope they don't stop at throwing out half of the code. > Meh, that's possible to some extent in most any language, but it takes a > lot of careful refactoring even in Forth, and people usually want to > just slam out code. These people fortunately don't use Forth. If you just slam out bad code in huge quantities, you get awful results. >> This is then still two orders of magnitude more than net2o. > > In the real world you have to interoperate with the stuff that's out > there. No, the stuff out there doesn't work and needs to be replaced, for god's sake! In the real world, you have people and machines who communicate, and apps who had no compatibility whatsoever with existing protocols like WhatsApp did have 100 million customers after a few years. This assumption that you have to stick with the heapload of shit that's out there has been proven wrong quite often. You have situations where you need interoperability, and you have situations where you don't need that. > Otherwise we'd all throw out existing natural languages and all > speak Esperanto or something. The main difference is that natural languages are spoken by men, and protocols are spoken by computers. And all it needs to get a computer to understand another protocol is to install a program. If you would be able to speak Esperanto or some other artificial or natural lingua franca (e.g. Mandarin to be able to talk to 1.5 billion people) after the 10 seconds it takes to download an app, you certainly would do it. The world outside I need to bother about is that I must pass through the routers that constitute the current Internet. I use UDP for that. That is a reality I can't ignore; though, of course, net2o as specified works fine without underlying layer 2 and 3 protocols. > SSL is complicated and crufty and is a > feature/misfeature of the reality that is out there and can't be > ignored. It is broken in so many ways that we have to replace it. It can't be fixed from within, the spec is already broken beyond repair (things like the CA system), and the glacial speed it has had in the past to improve known spec bugs (like adaption of TLS 1.2 to over TLS 1.0 and SSL3) shows that there's no hope to fix SSL by removing the stupid ideas and adding new good ones, and then hoping that Microsoft will implement that in a timely manner. This won't happen. >> And net2o doesn't just replace OpenSSL, it also replaces DNSSEC, and >> is going to replace PGP as well. > > It's certainly true that those things could be replaced with smaller > programs. Whether net2o can do all that and stay in the low-kloc range > remains to be seen, as well as whether it gets traction. It will be > great if it does of course. Don't forgot the requirement that it > perform comparably to OpenSSL, since people really do care about that. It performs far better. I know that performance is important, I've been shouted at (well, by e-mail ;-) by competing projects who also reinvent the Internet, and who have much worse performance, that I'm "obsessed by performance." I wouldn't even considder something with the performance of OpenSSL to be a contender. The competition is unencrypted communication, which is still used by a lot of people. I have to make sure that it competes with that (and where possible, like with the TCP flow control, I'm better - you can't do better than filling all available bandwidth, but you can do better by filling the available bandwidth faster, and be fairer to competing connections). >> The heartbleed bug is possible with Forth, too. The question is: >> Would a Forth programmer write such a protocol extension that only >> makes sense in an UDP-based protocol while SSL is TCP-based? Quite >> likely not. > > It was for DTLS which is UDP-based, i.e. DTLS extended SSL to handle > both TCP and UDP. I don't see that as having been inherently misguided > at first glance, though obviously it hit a bad implementation snag. Other people had quite different oppinions. > I don't find tinkering or debugging in Forth to be especially easier > than in Python, Lisp, or Erlang; and in those languages it's still quite > easy for bugs to get through. Yes, these programming languages are all interactive. If you cherry-pick languages that have similar features as Forth on a particular topic, you will get similar results. > The bugs of course usually manifest as > non-catastrophic runtime exceptions, Why do people always think that a runtime exception is non-catastrophic? The famous Ariane 5 debacle was caused by "non-catastrophic runtime exceptions". A runtime exception which stops the usual flow, and which isn't properly handled, can be catastrophic for a secure network protocol. An unexpected runtime exception quite likely won't be properly handled. > a big improvement over what happens > in C. The Haskell QuickCheck tool (basically an automatic fuzz tester) > has been ported to Erlang and people who have used it report good > results, compared to ad hoc interactive testing. Fuzz testers have their place, but the usually way to go is that you first have to make your program *work* at all. That phase requires injecting known good data, and observing what happens. Maybe the boilerplate fillers don't like doing this with interactive testing, i.e. a "test first" strategy, where you write a test which you can't run, because the program under test hasn't been written yet. > The thing is, with big programs, it's easy to make a small local change > that passes very thorough local testing, but ends up breaking something > in a remote part of the program. So you need extensive static checks > (enforced encapsulation counts as a form of static check) and/or large > automatic test suites that exercise all of the code. No, the thing you really need first is that you don't end up with a big program. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-04 22:46 -0700 |
| Message-ID | <7xbnu7ewo7.fsf@ruckus.brouhaha.com> |
| In reply to | #31142 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >>> The amount of bugs in a reviewed and "debugged" code-base is roughly the >>> same per kLoC.. >> What? No I don't believe that--for example TeX has had very few bugs >> reported in its entire history, while Linux has had hundreds. > TeX is an awfully small program by modern standards. ... Linux has > more than 10 million LoCs. You would expect it to have three orders > of magnitude more bugs than TeX. And indeed, it does. The big pile > of LaTeX extensions have a lot more bugs than TeX, the program. Hmm, yeah, that's true about TeX being relatively small but I still don't believe the bugs per kloc is similar, and your point about LaTeX corroborates that (less care was taken with the LaTeX extensions). I'd be interested in actual data. Particularly I haven't found the Altran/Praxis claims to be terribly implausible despite being a sales pitch: http://www.crosstalkonline.org/storage/issue-archives/2005/200512/200512-Croxford.pdf http://www.spectrum.ieee.org/sep05/1454 Basically they promote an approach (if I understand it from some of the other stuff I've seen about them) of writing detailed formal specifications of each function, then doing some lightweight formal verification of the simpler properties, and checking more complex properties with manual code reviews (I don't think they attempt full-blown machine verification of everything). They claim this results in an extremely low bug-per-KLOC rate compared to traditional methods. I have some reservations about their process but they don't affect the claims about correctness vs the specification. If you look at the bug density of CompCert vs. GCC or LLVM, the same thing is visible. Bugs in the (certified) backend are practically unknown. A few bugs in the (uncertified) front end have been found. CompCert is smaller but not orders of magnitude smaller. It has orders of magnitude fewer bugs. > People have analyzed security relevant programs in different programming > languages, and the number of security problems per amount of code was about > equal. Java Programmers make different mistakes. 1. I don't think you can consider all "security problems" to be equivalent. Spilling keys is much worse than almost any protocol error! 2. I think what may really be going on here is a kind of "risk thermostat" effect, where bugs decrease to a certain level because that level is tolerable to the development and release process, an issue orthogonal to the programming language. E.g. a typical internet shop will develop and test their code til it seems to work, then (if we're lucky) they release it to interested customers for beta test, collect further bug reports and fix those, and then when the bug reports slow down enough or stop, they release to production. Bugs are considered under control if enough less time is spent fixing them than implementing new features. For a lolcat app, that's not too bad a process. It's like making consumer electronics: if a DVD player basically works and doesn't break too easily, customers are happy. They don't want to pay 10x as much for a player programmed in Ada. And on the internet you can quickly roll out updates, which also feeds (crappy or streamlined, you pick the term) dev and test processes. For security code one really needs to seek to affirm the absence of bugs, rather than checking for their presence and saying "ok" if none are noticed. The code should preferably be treated as a mathematical object that one can prove theorems about, rather than an engineering artifact whose behavior can only be inferred from observing some tiny fragment of the state space. > Yes, it [OpenSSL] still is way too big... I hope they don't stop at > throwing out half of the code. One of the guys hacking code out of OpenSSL at a big web site recently told me they really do need a lot of the bloaty-looking code in it, that deals with buggy browsers, weird certificates, etc. >> In the real world you have to interoperate with the stuff that's out >> there. > No, the stuff out there doesn't work and needs to be replaced, for god's > sake! In the real world, you have people and machines who communicate, and > apps who had no compatibility whatsoever with existing protocols like > WhatsApp did have 100 million customers after a few years. That works when all endpoints of the application are controlled by a single organization. The issues with SSL are more like those of email or IPv4, where many independently controlled entities communicate with each other. If you want to design science fiction solutions for future generations, that's great as long as you recognize what it is. If you want to solve today's problems today, that means dealing with the stuff that's out there. > This assumption that you have to stick with the heapload of shit that's out > there has been proven wrong quite often. You have situations where you need > interoperability, and you have situations where you don't need that. In an odd (and bad) way, the desktop computer world is actually converging towards everything being controlled by one organization (i.e. Google). We don't even see word processors, spreadsheets, or email clients on desktops any more. It's all Gmail and Google Docs. Nobody is willing to install desktop apps these days. It may be a little different in the mobile space, where people will install unlimited spyware from "app stores"--that's how Whatsapp got around. Getting to that level of popularity isn't easy though, and even 100 million is only a few percent of the internet's users. Browsers with SSL reach close to 100%. > The world outside I need to bother about is that I must pass through the > routers that constitute the current Internet. I use UDP for that. I'm amused by the terrifying vision of enough applications migrating to browsers, simultaneously with net2o succeeding, so we end up with in-browser net2o stacks written in Javascript. > [SSL] is broken in so many ways that we have to replace it. It can't > be fixed from within, the spec is already broken beyond repair (things > like the CA system), The CA system is still with us because alternatives haven't fared better in implementing SSL's goals. It's not especially a technical weakness of SSL. I'd like to know how net2o is going to solve this problem. Replace SSL CA's by making people go to key signing parties before they can buy shoes online? > and the glacial speed it has had in the past to improve known spec > bugs (like adaption of TLS 1.2 to over TLS 1.0 and SSL3) I'll be interested to know how quickly net2o protocol changes are deployed, once there are hundreds of implementations, and it's running in billions of mobile phones (many of them obsolete and no longer receiving updates), home routers, industrial machinery, etc. >> Don't forgot the requirement that it perform comparably to OpenSSL, > It performs far better. I know that performance is important, OK, I see it uses Donna (ECC implementation) rather than a Forth implementation, so fine, other stuff can be handled similarly. Note there are faster ECC implementations than Donna now. > I wouldn't even considder something with the performance of OpenSSL to > be a contender. The competition is unencrypted communication, which > is still used by a lot of people. That's mostly because of deployment and configuration hassles rather than performance. >>Python, Lisp, or Erlang> > Yes, these programming languages are all interactive. If you cherry-pick > languages that have similar features as Forth on a particular topic, you > will get similar results. Well yes, you claimed Forth's interactivity was supposed to prevent bugs. I listed other interactive languages to indicate it's still quite possible to deploy buggy code despite the availability of interaction. >> The bugs of course usually manifest as non-catastrophic runtime >> exceptions, > > Why do people always think that a runtime exception is non-catastrophic? > The famous Ariane 5 debacle was caused by "non-catastrophic runtime > exceptions". What? No, that one was catastrophic and tools like SPARK put a lot of emphasis into proving that code is exception-free, for use in critical realtime systems. But we're talking about internet protocols, which are not realtime in the same way, and where applications must allow that the internet itself is inherently unreliable. If (say) a Java SSL stack throws an exception on someone trying a Heartbleed exploit, the result is that client experiencing a dropped connection, which is probably what you want anyway (plus you get a traceback in the server log and maybe an accompanying pager alert, rather than having the bug go unnoticed for years). > A runtime exception which stops the usual flow, and which isn't > properly handled, can be catastrophic for a secure network protocol. > An unexpected runtime exception quite likely won't be properly > handled. If the protocol is any good it has to be able to handle someone maliciously intercepting the connection and maybe even inserting their own data. If you treat exceptions (normally those will come from the i/o system) as similar to someone cutting the wire (i.e. report an error and give up), you're most of the way towards a sensible solution. >> The Haskell QuickCheck tool (basically an automatic fuzz tester) > Fuzz testers have their place, but the usually way to go is that you first > have to make your program *work* at all. That phase requires injecting > known good data, and observing what happens. Yes, and you have to test at the edge values, which are not always so easy to figure out, especially if you're the code author and if you over looked something in coding you're likely to also overlook it in testing. The cool thing about QuickCheck is you write the desired properties as the test, and QuickCheck itself generates the values, doing a reasonable job at guessing the edge cases itself, using Haskell's fine-grained type system to determine the possible good values. It frequently hits stuff that manual testing misses. > Maybe the boilerplate fillers don't like doing this with interactive > testing, i.e. a "test first" strategy, where you write a test which > you can't run, because the program under test hasn't been written yet. I'm not sure what you're getting at here. What happens when you refactor the program? Do you have to interactively re-test all the words? > No, the thing you really need first is that you don't end up with a > big program. Nice work if you can get it.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-05 13:27 +0000 |
| Message-ID | <53907053$0$4665$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #31201 |
In article <7xbnu7ewo7.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >Bernd Paysan <bernd.paysan@gmx.de> writes: >>>> The amount of bugs in a reviewed and "debugged" code-base is roughly the >>>> same per kLoC.. >>> What? No I don't believe that--for example TeX has had very few bugs >>> reported in its entire history, while Linux has had hundreds. >> TeX is an awfully small program by modern standards. ... Linux has >> more than 10 million LoCs. You would expect it to have three orders >> of magnitude more bugs than TeX. And indeed, it does. The big pile >> of LaTeX extensions have a lot more bugs than TeX, the program. > >Hmm, yeah, that's true about TeX being relatively small but I still >don't believe the bugs per kloc is similar, and your point about LaTeX >corroborates that (less care was taken with the LaTeX extensions). I'd >be interested in actual data. Particularly I haven't found the >Altran/Praxis claims to be terribly implausible despite being a sales >pitch: Do you mean plausible here? > > >http://www.crosstalkonline.org/storage/issue-archives/2005/200512/200512-Croxford.pdf > http://www.spectrum.ieee.org/sep05/1454 > >Basically they promote an approach (if I understand it from some of the >other stuff I've seen about them) of writing detailed formal >specifications of each function, then doing some lightweight formal >verification of the simpler properties, and checking more complex >properties with manual code reviews (I don't think they attempt >full-blown machine verification of everything). They claim this results >in an extremely low bug-per-KLOC rate compared to traditional methods. >I have some reservations about their process but they don't affect the >claims about correctness vs the specification. Manually checking the code against its detailed specification is what I do all the time. Detailed spec's got a bad reputation (for me) as part of the waterfall model, where they often don't lead to a correct program. (Or even make sense for that matter.) As a technique to arrive at a correct program they are invaluable. If I read a Forth word, I check its constituents against it specification [and no ( n -- n u ) is not a specification]. I don't check it against the code! If I suspect foul play I test the constituent against it specification. Then if it fails, I change the spec's or the code. The same technique is useful in solving a problem in large programs. Don't try to modify a module before you have a good (enough) formal specification of all the things it calls. Formal is not enough IMO. ( n -- n u ) is formal. That is not enough. Grounding also comes into play. Grounding is an artificial intelligence term and means the relation to the real world. For example in a pharmacy program you can talk about a recipe and expect the term to be understood by the programmer. It may require him to read a 500 page document. This is to ram some common sense (in the pharmacy sense) into the programmer, such that he doesn't do things that doesn't make sense in the pharmacy world. When I was going to do some programming at Shell, the team went on a week geology crash course. I remember problems at the Dutch railway, because some people understood a train to be at least three carriages, while others (programmers) thought a locomotive alone could be a train. The industry is developing in the wrong direction here. The real work is done by workers hired for the day. At the Hoogovens (Dutch steel) some one asked a worker to grind through a cable. Intended was (of course!) the steel cable that held up the construction that had been welded to held up an electric cable. Instead he ground through the electric cable. This worker was not grounded. He made the same mistake an "intelligent" robot could have made. I see similar situations in the computer industry. <SNIP> > >> No, the thing you really need first is that you don't end up with a >> big program. > >Nice work if you can get it. -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-05 08:39 -0700 |
| Message-ID | <7x4mzz1i3d.fsf@ruckus.brouhaha.com> |
| In reply to | #31202 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>I haven't found the Altran/Praxis claims to be terribly implausible > Do you mean plausible here? I mean the claims are plausible. Or at least, I haven't found them to be implausible. > Manually checking the code against its detailed specification is what > I do all the time. This is harder than it sounds. For example, the spec for some function might state a precondition: if X is an array of size N, then accessing X[K] requires that K be less than N. Say K is an input parameter and the spec says K < N and also says that the function can't throw exceptions. It's fairly easy to locally validate that by assuming K<N and inspecting the function. But verifying the program spec requires analyzing the entire program to make sure that it can never call the function with a value of K that is out of range. SPARK now has pretty good tools for checking that automatically, and Haskell is starting to get something like it too (search term: LiquidHaskell written as one word). > Formal is not enough IMO. ( n -- n u ) is formal. That is not enough. Formal but not detailed. > For example in a pharmacy program you can talk about a recipe > and expect the term to be understood by the programmer. It may > require him to read a 500 page document. This is to ram some common sense > (in the pharmacy sense) into the programmer, such that he doesn't do > things that doesn't make sense in the pharmacy world. In the Altran approach they formalize those requirements in a notation based on set theory. Seems workable up to a point.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-05 16:10 +0000 |
| Message-ID | <53909670$0$4707$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #31205 |
In article <7x4mzz1i3d.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>I haven't found the Altran/Praxis claims to be terribly implausible >> Do you mean plausible here? > >I mean the claims are plausible. Or at least, I haven't found them to >be implausible. I misunderstood. > >> Manually checking the code against its detailed specification is what >> I do all the time. > >This is harder than it sounds. No need to tell me. >For example, the spec for some function >might state a precondition: if X is an array of size N, then accessing >X[K] requires that K be less than N. Say K is an input parameter and >the spec says K < N and also says that the function can't throw >exceptions. It's fairly easy to locally validate that by assuming K<N >and inspecting the function. If I've specified that K<N my job is done. That is an important part of the job. If you can't throw an exception, at least they must allow you to log that things are wrong. > But verifying the program spec requires >analyzing the entire program to make sure that it can never call the >function with a value of K that is out of range. SPARK now has pretty >good tools for checking that automatically, and Haskell is starting to >get something like it too (search term: LiquidHaskell written as one >word). Calling the function correctly is the responsibility of the person writing that other function, before automatic tools come into play. [Of course it comes down to me, discovering K<N after they assign me the job of fixing a buggy program.] > >> Formal is not enough IMO. ( n -- n u ) is formal. That is not enough. > >Formal but not detailed. > >> For example in a pharmacy program you can talk about a recipe >> and expect the term to be understood by the programmer. It may >> require him to read a 500 page document. This is to ram some common sense >> (in the pharmacy sense) into the programmer, such that he doesn't do >> things that doesn't make sense in the pharmacy world. > >In the Altran approach they formalize those requirements in a notation >based on set theory. Seems workable up to a point. I', suspicious. It only works if the Altran expert reads the 500 page document. This approach is mostly taken because management believes nobody needs to read the 500 page document. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-05 11:10 -0700 |
| Message-ID | <7xvbsfz0pu.fsf@ruckus.brouhaha.com> |
| In reply to | #31206 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>the spec says K < N and also says that the function can't throw >>exceptions.... > If I've specified that K<N my job is done. Only for the immediate implementation of the function. > That is an important part of the job. If you can't throw an exception, > at least they must allow you to log that things are wrong. In an embedded realtime device, where are you going to write the log? What I'm getting at is the verification process really does require ensuring that K < N at all of the call sites, not just that the function using K works properly given the precondition. > I', suspicious. It only works if the Altran expert reads the 500 page > document. This approach is mostly taken because management believes > nobody needs to read the 500 page document. The Altran specification process involves reading the 500 page document and translating it to a Z notation spec. Then they get the customer to sign off on the spec, and then they write the code which they guarantee conforms to the spec. There is an obvious potential scam here: the Z notation probably looks like mathematical gibberish to the customer, so maybe they shrug their shoulders and sign. Then if the program does something the customer didn't expect, they call Altran, which checks that the unexpected thing really was what the formal spec said to do, so the customer can pay for a spec change but they can't invoke the guarantee, since the implementation conforms to the existing customer-accepted spec. I don't know if that's a problem in practice. Altran does ship real systems that are highly regarded.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-05 19:52 +0000 |
| Message-ID | <5390ca6e$0$4961$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31210 |
In article <7xvbsfz0pu.fsf@ruckus.brouhaha.com>, Paul Rubin <no.email@nospam.invalid> wrote: >albert@spenarnc.xs4all.nl (Albert van der Horst) writes: >>>the spec says K < N and also says that the function can't throw >>>exceptions.... >> If I've specified that K<N my job is done. > >Only for the immediate implementation of the function. > >> That is an important part of the job. If you can't throw an exception, >> at least they must allow you to log that things are wrong. > >In an embedded realtime device, where are you going to write the log? That's why no embedded device should be without w beeper or a led that I can blink. >What I'm getting at is the verification process really does require >ensuring that K < N at all of the call sites, not just that the function >using K works properly given the precondition. > >> I', suspicious. It only works if the Altran expert reads the 500 page >> document. This approach is mostly taken because management believes >> nobody needs to read the 500 page document. > >The Altran specification process involves reading the 500 page document >and translating it to a Z notation spec. Then they get the customer to >sign off on the spec, and then they write the code which they guarantee >conforms to the spec. There is an obvious potential scam here: the Z >notation probably looks like mathematical gibberish to the customer, so >maybe they shrug their shoulders and sign. Then if the program does >something the customer didn't expect, they call Altran, which checks >that the unexpected thing really was what the formal spec said to do, so >the customer can pay for a spec change but they can't invoke the >guarantee, since the implementation conforms to the existing >customer-accepted spec. > >I don't know if that's a problem in practice. Altran does ship real >systems that are highly regarded. Sounds good. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-06-05 23:25 +0200 |
| Message-ID | <lmqn8g$ise$1@online.de> |
| In reply to | #31210 |
Paul Rubin wrote: > The Altran specification process involves reading the 500 page document > and translating it to a Z notation spec. Then they get the customer to > sign off on the spec, and then they write the code which they guarantee > conforms to the spec. There is an obvious potential scam here: the Z > notation probably looks like mathematical gibberish to the customer, so > maybe they shrug their shoulders and sign. Then if the program does > something the customer didn't expect, they call Altran, which checks > that the unexpected thing really was what the formal spec said to do, so > the customer can pay for a spec change but they can't invoke the > guarantee, since the implementation conforms to the existing > customer-accepted spec. > > I don't know if that's a problem in practice. Altran does ship real > systems that are highly regarded. Customers getting what they said they wanted but isn't what they actually needed and customers confused about formal stuff are frequently seen. A 500 page document has already enough mistakes in it that converting it to a formal spec that is very likely gibberish to the customer won't get you a product that works as it should. Specification bugs are the most expensive bugs. Often, they are just omissions, things that the device should do but nobody thought about it. I remember several analog components failing in the chip projects I did for Mikron, because the customer overlooked something when writing the spec. One was the noise level: That device had a small signal AM input (microvolts), and at the start of the project, I wanted to talk the customer into a synchronous demodulator. They refused, and took a rectifier instead. A recitifer produces twice the noise as a synchronous demodulator (that's because in a rectifier, the area matters, whereas for a synchronous demodulator, the peak amplitude matters). This factor of two in the noise wasn't expected by the customer, and I didn't expect they hadn't calculated for that - after all, the argument with the rectifier was that they had always used a rectifier (you know, this sort of stupid arguments "we have always done it like that" ;-). I had to fly to silicon valley to measure the entire chain with them together, and it was obvious that we did meet the spec requirements up to the rectifier. And after the rectifier, the noise was twice as high as they expected. They didn't want to hear me saying "I told you so, use a synchronous demodulator", because of course at that point in time it was way too late - the entire chip worked well, just the noise was too high. They had to repeat the measurement for four times to reduce the noise to an acceptable level, as workaround (that was doable). The other thing was a variable gain adapter, also with potentially quite small signal. The specification said that offset should be cancelled, but failed to say that a change in gain must not affect the offset, not even temporarily. This thing required a complete redesign. Usually, the idea that you have a solid spec, even formalized, at the start of the project, is already a recipie for disaster. What you really need is knowledge in the application domain; and that rarely happens in typical commercial settings. The reason why XP demands "user stories" is that this sort of informal specification right from the end user to the implementer cuts down all those middle men who think they know what the user wants. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2014-06-05 15:02 -0700 |
| Message-ID | <7xbnu7816j.fsf@ruckus.brouhaha.com> |
| In reply to | #31222 |
Bernd Paysan <bernd.paysan@gmx.de> writes: > Specification bugs are the most expensive bugs. Often, they are just > omissions, things that the device should do but nobody thought about it. I don't think formalized specs usually capture every desired behavior of the program. They just identify various behaviors that are required or prohibited, leaving some parts up to informal processes. The formal part eliminates large classes of bugs, and writing the specs often helps clarify one's understanding of the problem. Example: the CompCert spec says the compiler has to preserve the program semantics, but it doesn't identify all the optimizations that the compiler is supposed to do. Those are chosen by the implementer in more or less the usual way, based on understanding of how compilers normally work and what is expected of them.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-06 10:56 +0000 |
| Message-ID | <53919e53$0$4852$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31222 |
In article <lmqn8g$ise$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Paul Rubin wrote: >> The Altran specification process involves reading the 500 page document >> and translating it to a Z notation spec. Then they get the customer to >> sign off on the spec, and then they write the code which they guarantee >> conforms to the spec. There is an obvious potential scam here: the Z >> notation probably looks like mathematical gibberish to the customer, so >> maybe they shrug their shoulders and sign. Then if the program does >> something the customer didn't expect, they call Altran, which checks >> that the unexpected thing really was what the formal spec said to do, so >> the customer can pay for a spec change but they can't invoke the >> guarantee, since the implementation conforms to the existing >> customer-accepted spec. >> >> I don't know if that's a problem in practice. Altran does ship real >> systems that are highly regarded. > >Customers getting what they said they wanted but isn't what they actually >needed and customers confused about formal stuff are frequently seen. A 500 >page document has already enough mistakes in it that converting it to a >formal spec that is very likely gibberish to the customer won't get you a >product that works as it should. > >Specification bugs are the most expensive bugs. Often, they are just >omissions, things that the device should do but nobody thought about it. > >I remember several analog components failing in the chip projects I did for >Mikron, because the customer overlooked something when writing the spec. >One was the noise level: That device had a small signal AM input >(microvolts), and at the start of the project, I wanted to talk the customer >into a synchronous demodulator. They refused, and took a rectifier instead. >A recitifer produces twice the noise as a synchronous demodulator (that's >because in a rectifier, the area matters, whereas for a synchronous >demodulator, the peak amplitude matters). This factor of two in the noise >wasn't expected by the customer, and I didn't expect they hadn't calculated >for that - after all, the argument with the rectifier was that they had >always used a rectifier (you know, this sort of stupid arguments "we have >always done it like that" ;-). I had to fly to silicon valley to measure >the entire chain with them together, and it was obvious that we did meet the >spec requirements up to the rectifier. And after the rectifier, the noise >was twice as high as they expected. > >They didn't want to hear me saying "I told you so, use a synchronous >demodulator", because of course at that point in time it was way too late - >the entire chip worked well, just the noise was too high. They had to >repeat the measurement for four times to reduce the noise to an acceptable >level, as workaround (that was doable). > >The other thing was a variable gain adapter, also with potentially quite >small signal. The specification said that offset should be cancelled, but >failed to say that a change in gain must not affect the offset, not even >temporarily. This thing required a complete redesign. > >Usually, the idea that you have a solid spec, even formalized, at the start >of the project, is already a recipie for disaster. What you really need is >knowledge in the application domain; and that rarely happens in typical >commercial settings. The reason why XP demands "user stories" is that this >sort of informal specification right from the end user to the implementer >cuts down all those middle men who think they know what the user wants. My example of the 500 document was exactly that: building feel for the application domain. It could be replaced by a series of 5 DVD's "what's up at the navy". A good example is also the booklet we got at the Dutch railway to get acquainted with the railway world. It is *not* in any way a specification document. It is totally unrelated in fact to the project at hand. > >-- >Bernd Paysan Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Paul E Bennett <Paul_E.Bennett@topmail.co.uk> |
|---|---|
| Date | 2014-06-09 09:59 +0100 |
| Subject | Correct Software and Specifications (was Re: MSP430-Stamp) |
| Message-ID | <bvlbb5FocnkU1@mid.individual.net> |
| In reply to | #31210 |
Paul Rubin wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>the spec says K < N and also says that the function can't throw
>>>exceptions....
>> If I've specified that K<N my job is done.
>
> Only for the immediate implementation of the function.
>
>> That is an important part of the job. If you can't throw an exception,
>> at least they must allow you to log that things are wrong.
>
> In an embedded realtime device, where are you going to write the log?
> What I'm getting at is the verification process really does require
> ensuring that K < N at all of the call sites, not just that the function
> using K works properly given the precondition.
>
>> I', suspicious. It only works if the Altran expert reads the 500 page
>> document. This approach is mostly taken because management believes
>> nobody needs to read the 500 page document.
>
> The Altran specification process involves reading the 500 page document
> and translating it to a Z notation spec. Then they get the customer to
> sign off on the spec, and then they write the code which they guarantee
> conforms to the spec. There is an obvious potential scam here: the Z
> notation probably looks like mathematical gibberish to the customer, so
> maybe they shrug their shoulders and sign. Then if the program does
> something the customer didn't expect, they call Altran, which checks
> that the unexpected thing really was what the formal spec said to do, so
> the customer can pay for a spec change but they can't invoke the
> guarantee, since the implementation conforms to the existing
> customer-accepted spec.
>
> I don't know if that's a problem in practice. Altran does ship real
> systems that are highly regarded.
I think the important thing to take away from the Altran-Praxis articles is
that:-
* They have a definite Develeopment Process that they adhere to and are
able to provide auditable proof of that fact.
* They expend more effort on obtaining the correct, complete,
coherent specification than most other software shops. They
stated more than 50% of their project effort is expended
before they churn production code out.
* They ensure the buy in of the client for the specification that
is to be implemented (I don't think that the client needs to
fully understand the math for this as once a spec has mathematically
coherent backing it becomes easier to describe in words).
* No one I know at Altran-Praxis would claim that they could deal with
mathematical proofs for every aspect of some systems. They readily
recognise and admit the limitations of their tools.
Of course, as Forthists, you are already using a reasonably formal
environment in your developments that has been described as partly
functional and partly procedural. How good is your process on the CMM scale?
Can you prove it? Happy to talk more on this at EuroForth.
--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2014-06-05 14:30 -0700 |
| Message-ID | <e1613a49-e9b7-4beb-9d6a-dc46b19f8fec@googlegroups.com> |
| In reply to | #31202 |
On Thursday, June 5, 2014 2:27:47 PM UTC+1, Albert van der Horst wrote: [..] > Instead he ground through the > electric cable. This worker was not grounded. Two wrongs making one lucky guy. -marcel
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web