Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #74757 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-11-03 06:31 -0800 |
| Last post | 2015-11-20 10:43 +0000 |
| Articles | 20 on this page of 167 — 29 participants |
Back to article view | Back to comp.lang.c
Is it possible C is the security problem? G G <gdotone@gmail.com> - 2015-11-03 06:31 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 14:57 +0000
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-03 15:04 +0000
Re: Is it possible C is the security problem? G G <gdotone@gmail.com> - 2015-11-03 07:11 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 15:25 +0000
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-03 20:13 +0000
Re: Is it possible C is the security problem? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-03 15:18 -0500
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 20:34 +0000
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-03 22:47 +0000
Re: Is it possible C is the security problem? Udyant Wig <udyantw@gmail.com> - 2015-11-04 15:36 +0530
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 10:34 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-03 15:18 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 17:42 -0800
Re: Is it possible C is the security problem? Geoff <geoff@invalid.invalid> - 2015-11-03 15:32 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 23:57 +0000
Re: Is it possible C is the security problem? Geoff <geoff@invalid.invalid> - 2015-11-03 21:13 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 07:22 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-04 11:32 +0100
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 10:54 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-04 13:38 +0100
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-07 08:27 +0000
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-05 09:26 +0000
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 10:03 +0000
Re: Is it possible C is the security problem? James Kuyper <jameskuyper@verizon.net> - 2015-11-05 08:53 -0500
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-06 10:04 +0000
Re: Is it possible C is the security problem? Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 21:06 +0800
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-05 11:14 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-05 11:44 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 02:43 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-07 17:30 -0800
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:35 +0000
Re: Is it possible C is the security problem? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-10 11:52 -0500
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-11 00:48 -0600
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-17 21:55 +0000
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 19:14 -0600
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 03:40 +0000
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:01 -0600
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-18 09:00 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 09:09 -0800
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-18 15:35 -0600
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 21:35 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 20:38 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-19 05:40 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-18 22:55 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-19 19:56 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-18 23:40 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-19 21:05 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-19 06:40 -0800
Re: Is it possible C is the security problem? asetofsymbols@gmail.com - 2015-11-19 11:37 -0800
Re: Is it possible C is the security problem? asetofsymbols@gmail.com - 2015-11-19 12:09 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-19 12:52 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-20 12:20 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-19 15:34 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-22 16:43 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-21 21:28 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-22 20:51 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-22 07:26 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-22 09:42 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-22 09:59 -0800
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 07:08 +0000
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-23 11:57 +1300
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-22 16:06 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-23 13:26 +1300
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-19 09:09 +0000
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-20 02:29 -0800
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-20 12:33 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-20 09:26 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 13:37 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-19 14:07 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-20 01:38 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-19 18:43 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-20 12:09 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 01:48 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-20 11:16 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 05:04 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-20 18:18 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 11:55 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 00:27 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 18:57 -0800
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-20 19:50 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 20:06 -0800
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-20 20:46 -0800
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 20:56 -0800
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 04:58 -0600
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-21 04:59 -0800
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 13:26 -0600
Re: Is it possible C is the security problem? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-21 14:38 -0500
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 06:49 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 22:56 -0800
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 04:36 -0600
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 06:44 +0000
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 15:59 +0000
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 18:33 +0000
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-21 19:19 +0000
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 13:33 -0600
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:42 +0000
Re: Is it possible C is the security problem? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:17 -0800
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-20 14:51 +1300
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-19 08:06 -0600
Re: Is it possible C is the security problem? Robert Wessel <robertwessel2@yahoo.com> - 2015-11-18 15:40 -0600
Re: Is it possible C is the security problem? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:57 -0800
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 06:56 +0000
Re: Is it possible C is the security problem? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 03:16 -0800
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 22:28 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-23 21:11 -0800
Re: Is it possible C is the security problem? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-24 10:29 -0800
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 02:38 +0000
Re: Is it possible C is the security problem? Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 13:54 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-10 10:23 -0800
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-10 11:21 -0800
Re: Is it possible C is the security problem? Melzzzzz <mel@zzzzz.com> - 2015-11-04 00:58 +0100
Re: Is it possible C is the security problem? Les Cargill <lcargill99@comcast.com> - 2015-11-03 18:26 -0600
Re: Is it possible C is the security problem? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-04 02:06 +0000
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-04 14:12 +1300
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 07:02 +0000
Re: Is it possible C is the security problem? Ian Collins <ian-news@hotmail.com> - 2015-11-04 20:42 +1300
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 08:06 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-04 11:25 +0100
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-04 11:49 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-04 13:46 +0100
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-17 21:58 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-17 23:37 +0100
Re: Is it possible C is the security problem? David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:55 -0500
Re: Is it possible C is the security problem? Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:23 -0600
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-03 15:59 +0000
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-03 16:55 +0000
Re: Is it possible C is the security problem? see.my.homepage@gmail.com - 2015-11-04 02:29 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 10:48 +0000
Re: Is it possible C is the security problem? see.my.homepage@gmail.com - 2015-11-04 14:11 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 00:39 +0000
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 01:15 +0000
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 02:02 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-04 18:31 -0800
Re: Is it possible C is the security problem? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 12:38 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-04 18:24 -0800
Re: Is it possible C is the security problem? Keith Thompson <kst-u@mib.org> - 2015-11-04 19:37 -0800
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-05 13:24 +0100
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-05 06:47 -0800
Re: Is it possible C is the security problem? see.my.homepage@gmail.com - 2015-11-05 00:35 -0800
Re: Is it possible C is the security problem? Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 09:55 +0000
Re: Is it possible C is the security problem? see.my.homepage@gmail.com - 2015-11-05 05:02 -0800
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-06 10:18 +0000
Re: Is it possible C is the security problem? see.my.homepage@gmail.com - 2015-11-06 05:57 -0800
Re: Is it possible C is the security problem? James Kuyper <jameskuyper@verizon.net> - 2015-11-04 08:32 -0500
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-03 15:01 +0000
Re: Is it possible C is the security problem? Bartc <bc@freeuk.com> - 2015-11-03 15:10 +0000
Re: Is it possible C is the security problem? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-03 11:02 -0500
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-03 18:13 +0000
Re: Is it possible C is the security problem? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-03 15:16 -0500
Re: Is it possible C is the security problem? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-04 09:38 +0000
Re: Is it possible C is the security problem? David Brown <david.brown@hesbynett.no> - 2015-11-04 11:38 +0100
Re: Is it possible C is the security problem? James Kuyper <jameskuyper@verizon.net> - 2015-11-03 11:58 -0500
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-03 09:13 -0800
Re: Is it possible C is the security problem? gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-03 18:08 +0000
Re: Is it possible C is the security problem? Nobody <nobody@nowhere.invalid> - 2015-11-04 04:49 +0000
Re: Is it possible C is the security problem? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-04 02:22 -0800
Re: Is it possible C is the security problem? gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-04 13:28 +0000
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-04 08:39 -0800
Re: Is it possible C is the security problem? John Bode <jfbode1029@gmail.com> - 2015-11-03 10:45 -0800
Re: Is it possible C is the security problem? supercat@casperkitty.com - 2015-11-03 11:05 -0800
Re: Is it possible C is the security problem? Les Cargill <lcargill99@comcast.com> - 2015-11-03 18:09 -0600
Is it possible C is the security problem? Chad <cdalten@gmail.com> - 2015-11-04 01:15 -0800
Re: Is it possible C is the security problem? gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-04 13:31 +0000
Re: Is it possible C is the security problem? G G <gdotone@gmail.com> - 2015-11-18 10:55 -0800
Re: Is it possible C is the security problem? James Kuyper <jameskuyper@verizon.net> - 2015-11-18 14:05 -0500
Re: Is it possible C is the security problem? "D. Aaron Sawyer" <aaron@110.net> - 2015-11-18 19:47 -0500
Re: Is it possible C is the security problem? raltbos@xs4all.nl (Richard Bos) - 2015-11-20 10:43 +0000
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-17 21:58 +0000 |
| Message-ID | <564ba260.24832515@news.xs4all.nl> |
| In reply to | #74813 |
David Brown <david.brown@hesbynett.no> wrote: > No programming language will fix this. "Fixing" the programmers will > seldom fix it either - it is the apparatus /around/ the actual coding > that needs fixed. The TLS library programmers were a small group, with > little or no funding, working away by themselves without review or > outside checks or controls. > > So the way to avoid such problems (IMHO) is to give the people behind > such important software an appropriate level of support. Pay them for > the work, so that they can do it full-time and not just as a hobby. Pay > others to check the code. Pay for computers powerful enough for massive > testing. Pay for someone to document the code, and someone to manage > the project. Pay for the /boring/ stuff that rarely receives the care > needed when code is written voluntarily. A great many people make money > from software or services that depend critically on the code behind > Heartbleed - they often contribute money, people and resources to all > sorts of open source software, but they need to be a good deal better at > making sure they also support these quite yet critical projects as a > well as the big and visible ones. But those aren't flashy and sparkling. Open-source is very good at attracting geeks to shiny! nifty! projects, but not good at all at getting professionals (and you're going to _need_ professionals) to do the nitty-gritty. For that, you have to have commercial solutions. Now, I'm not saying a joint venture between commerce and open source is impossible - in fact, we know it is possible... but also that it's hard. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-17 23:37 +0100 |
| Message-ID | <n2ga2b$ao8$2@dont-email.me> |
| In reply to | #76298 |
On 17/11/15 22:58, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> No programming language will fix this. "Fixing" the programmers will >> seldom fix it either - it is the apparatus /around/ the actual coding >> that needs fixed. The TLS library programmers were a small group, with >> little or no funding, working away by themselves without review or >> outside checks or controls. >> >> So the way to avoid such problems (IMHO) is to give the people behind >> such important software an appropriate level of support. Pay them for >> the work, so that they can do it full-time and not just as a hobby. Pay >> others to check the code. Pay for computers powerful enough for massive >> testing. Pay for someone to document the code, and someone to manage >> the project. Pay for the /boring/ stuff that rarely receives the care >> needed when code is written voluntarily. A great many people make money >> from software or services that depend critically on the code behind >> Heartbleed - they often contribute money, people and resources to all >> sorts of open source software, but they need to be a good deal better at >> making sure they also support these quite yet critical projects as a >> well as the big and visible ones. > > But those aren't flashy and sparkling. Open-source is very good at > attracting geeks to shiny! nifty! projects, but not good at all at > getting professionals (and you're going to _need_ professionals) to do > the nitty-gritty. For that, you have to have commercial solutions. Now, > I'm not saying a joint venture between commerce and open source is > impossible - in fact, we know it is possible... but also that it's hard. > Actually, most serious open source software is already a joint venture between commercial development and volunteer work (I believe something like 75% of Linux kernel work is from professionals paid to do the job). But sometimes small but vital projects, such as this SSL stuff, get forgotten by the big commercial backers as they had appeared to be doing a perfectly good job.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-06 07:55 -0500 |
| Message-ID | <82c86b5fp5uuf0s2r6enc2ldq1eo2331rd@4ax.com> |
| In reply to | #74765 |
On Tue, 3 Nov 2015 15:25:51 +0000, Richard Heathfield <rjh@cpax.org.uk> wrote: <snip> > Take Heartbleed as an example. > > This is an example of a new vulnerability that was introduced (in 2012, > I think?) into previously secure (well, as far as we know) code. > > The idea of Heartbeat was to allow TLS/DTLS to keep a connection alive > by sending occasional "heartbeat" packets. Alice sends Bob some data, > Bob sends it back, and thus Alice and Bob prove to each other that they > are still alive. How much data? Alice tells Bob this, and *Bob believes > her*! And that was how the Heartbleed exploit was made possible: <snip> Actually heartbeat was two ideas conflated, see RFC 6520: * "are you there" for both TLS and DTLS; this doesn't need variable data, or even any data (cf ChangeCipherSpec, HelloRequest) * generic PMTU discovery for DTLS only, since TCP does it for TLS but UDP doesn't do it for DTLS; this needs variable rather large data If these had been separate features, and only the first was desired and implemented in OpenSSL, there would have been no Heartbleed. Does that make the spec unsafe? Unwise? Mu.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-12-06 14:23 -0600 |
| Message-ID | <n4251b$oi5$3@dont-email.me> |
| In reply to | #77967 |
David Thompson wrote: > On Tue, 3 Nov 2015 15:25:51 +0000, Richard Heathfield > <rjh@cpax.org.uk> wrote: > <snip> >> Take Heartbleed as an example. >> >> This is an example of a new vulnerability that was introduced (in 2012, >> I think?) into previously secure (well, as far as we know) code. >> >> The idea of Heartbeat was to allow TLS/DTLS to keep a connection alive >> by sending occasional "heartbeat" packets. Alice sends Bob some data, >> Bob sends it back, and thus Alice and Bob prove to each other that they >> are still alive. How much data? Alice tells Bob this, and *Bob believes >> her*! And that was how the Heartbleed exploit was made possible: <snip> > > Actually heartbeat was two ideas conflated, see RFC 6520: > > * "are you there" for both TLS and DTLS; this doesn't need variable > data, or even any data (cf ChangeCipherSpec, HelloRequest) > > * generic PMTU discovery for DTLS only, since TCP does it for TLS but > UDP doesn't do it for DTLS; this needs variable rather large data > > If these had been separate features, and only the first was desired > and implemented in OpenSSL, there would have been no Heartbleed. > Does that make the spec unsafe? Unwise? Mu. > Exactly. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-03 15:59 +0000 |
| Message-ID | <87pozr3whg.fsf@bsb.me.uk> |
| In reply to | #74758 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 03/11/15 14:31, G G wrote: >> Is it possible C, the language itself, is the problem not just the >> implementation of it. > > Is C a perfect language? No. Would writing everything in some other > language mean we never had any security flaws? No. So is C the > problem? No. Right, but by borrowing G G's very specific language -- "the problem" -- you've side-stepped the issue. Is the ubiquity of C part of the problem? Are there things about C that make writing correct programs harder than it need be? If more people used other languages would there be fewer security flaws? I don't know the answer, but do think the question merits more sophisticated analysis than your rather absolutist logic suggests. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-03 16:55 +0000 |
| Message-ID | <n1aopv$vf8$1@dont-email.me> |
| In reply to | #74766 |
On 03/11/15 15:59, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 03/11/15 14:31, G G wrote: >>> Is it possible C, the language itself, is the problem not just the >>> implementation of it. >> >> Is C a perfect language? No. Would writing everything in some other >> language mean we never had any security flaws? No. So is C the >> problem? No. > > Right, but by borrowing G G's very specific language -- "the problem" -- > you've side-stepped the issue. Is the ubiquity of C part of the > problem? Are there things about C that make writing correct programs > harder than it need be? If more people used other languages would > there be fewer security flaws? > > I don't know the answer, but do think the question merits more > sophisticated analysis than your rather absolutist logic suggests. Whose question? I would agree that your questions merit closer inspection but, as you have recognised, my answer dealt with the problem as stated. If the OP wants a more sophisticated answer, he'll need a more sophisticated question. (Or he could borrow yours.) I'm tempted to provide quick answers to the question you posed, but although I do have a little spare time right now, I don't have anything like enough spare time to do those questions justice. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | see.my.homepage@gmail.com |
|---|---|
| Date | 2015-11-04 02:29 -0800 |
| Message-ID | <660e1300-4ef9-48a2-a170-86372552b4d6@googlegroups.com> |
| In reply to | #74758 |
> Is C a perfect language? No. Correct. > Would writing everything in some other > language mean we never had any security flaws? No. Correct. But you have carefully hidden an important part: never having any security flaws is completely different from having less of them that we have today. If we can have less, I'm all for it, even if it is still not exactly zero. > So is C the problem? No. Incorrect. You did not answer this question because you have escaped from addressing that other important part. If we can have less security flaws by using another language, then certainly and by all means, C *is* a problem. > Is the implementation of C perfect? No. If we had a perfect > implementation of C, would that mean we never had any security flaws? > No. So is the implementation of C the problem? No. Same pattern as above. Wrong logic - wrong conclusions. > No, it turns out that, as usual, the problem is people. Yes. > Rather than break C in an attempt to obtain an unattainable goal - a > language in which all programs are secure - I think our time would be > better spent teaching people that Short Cuts Are Bad. It's a lesson that > has *still* not been learned, after all these decades. In which case perhaps learning this lesson is not feasible. Well, at least those *decades* give us strong evidence about that. In which case moving to another language might be a solution. In other words, if you cannot fix the people who cannot learn how to use broken tools, then fix the tools. Why is it such a problem? -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-04 10:48 +0000 |
| Message-ID | <n1cnl1$il0$1@dont-email.me> |
| In reply to | #74815 |
On 04/11/15 10:29, see.my.homepage@gmail.com wrote: > >> Is C a perfect language? No. > > Correct. > >> Would writing everything in some other >> language mean we never had any security flaws? No. > > Correct. But you have carefully hidden an important part: > never having any security flaws is completely different > from having less of them that we have today. If we can > have less, I'm all for it, even if it is still not > exactly zero. Careful. I didn't carefully hide anything. It is true that having fewer security flaws is a good thing. That does not imply ipso facto that moving away from C will result in fewer security flaws. It might turn out to mean that, but this hasn't been demonstrated. What's more, although security is indeed very important, there are other very important aspects of programming as well. When selecting a language, one must take these other aspects into account too. For example: readability, correctness, performance, portability, flexibility, and (often) even the familiarity of the project team with the language. Sometimes you just have to work with the skills you have available to you. >> So is C the problem? No. > > Incorrect. You did not answer this question because you > have escaped from addressing that other important part. I just addressed it now - and please have a care to choose your words more carefully. I wasn't escaping from anything. > If we can have less security flaws by using another > language, then certainly and by all means, C *is* a problem. The question was not "is C a problem" but "is C /the/ problem", and it isn't, so my answer was correct. There are undoubtedly ways of using C that lead to security vulnerabilities, but that's true of any language. That is, for any language you care to name, I can come up with a security vulnerability that it would be possible to perpetrate in that language. (That is, it is easily possible to come up with a security vulnerability in an *algorithm*, in which case any language that faithfully implements the algorithm will faithfully implement the vulnerability too.) >> Is the implementation of C perfect? No. If we had a perfect >> implementation of C, would that mean we never had any security flaws? >> No. So is the implementation of C the problem? No. > > Same pattern as above. Wrong logic - wrong conclusions. I disagree for the reasons I have stated above. > >> No, it turns out that, as usual, the problem is people. > > Yes. Quite. > >> Rather than break C in an attempt to obtain an unattainable goal - a >> language in which all programs are secure - I think our time would be >> better spent teaching people that Short Cuts Are Bad. It's a lesson that >> has *still* not been learned, after all these decades. > > In which case perhaps learning this lesson is not feasible. Well, > at least those *decades* give us strong evidence about that. In > which case moving to another language might be a solution. In > other words, if you cannot fix the people who cannot learn how > to use broken tools, Maybe we just need better teachers. Maybe experience is one of those better teachers. We all take more care than we used to, right? > then fix the tools. Why is it such a problem? You're assuming that C is a broken tool. I don't think it is broken. I just think it's a *powerful* tool, and as such needs careful handling. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | see.my.homepage@gmail.com |
|---|---|
| Date | 2015-11-04 14:11 -0800 |
| Message-ID | <5985bb23-835e-4655-8f60-da3c6a99aa71@googlegroups.com> |
| In reply to | #74821 |
> Careful. I didn't carefully hide anything. It is true that having fewer > security flaws is a good thing. That does not imply ipso facto that > moving away from C will result in fewer security flaws. It might turn > out to mean that, but this hasn't been demonstrated. Yes, it was demonstrated, in many different ways. For example, at the low level, a language that does not allow (statically or dynamically) to overrun an array, will not have the vulnerabilities associated with overrunning of arrays and we know that many security flaws result from those. Just getting rid of this single issue would improve software security in a way that would be certainly visible and appreciated. > What's more, > although security is indeed very important, there are other very > important aspects of programming as well. Yes. > For example: > readability, C is one of the least readable languages ever invented. The obfuscated C contest would not be established without this property. > correctness, C does not provide any correctness-oriented tools for the programmer. > performance, portability, It is possible to achieve them without compromising security. > flexibility, What does that mean? > and > (often) even the familiarity of the project team with the language. But you have just stated that people in general do not get it, so why "familiarity" is an argument? > There are undoubtedly ways of using C > that lead to security vulnerabilities, but that's true of any language. > That is, for any language you care to name, I can come up with a > security vulnerability that it would be possible to perpetrate in that > language. It does not matter. The problem with security vulnerabilities is that they are easy to fall into - unwillingly. Any other language that makes it harder to do insecure things (like overruning the array) would be better, because, statistically speaking, programmers would fall into them less often. The idea is to make it harder to make errors, not to make it entirely impossible. In other words, by selecting from the intentionally limited set of options, you have again fell into the same logic trap as before. > (That is, it is easily possible to come up with a security > vulnerability in an *algorithm*, in which case any language that > faithfully implements the algorithm will faithfully implement the > vulnerability too.) Great idea. Let take some security-related algorithm as an example: http://www.adacore.com/press/spark-skein/ "It is stunning how the formal verification of the SPARK source code actually made us discover a flaw in our own reference C implementation." (there are some interesting statements about performance and readability, too) Good languages can not only make it more difficult to overrun an array, but also make it more difficult to write incorrect algorithm. > Maybe we just need better teachers. Unfortunately, no. For two reasons. First is that people do not listen. This discussion (like many other similar discussions) is a good example. The other one is that we already have *decades* of experience telling us that people are unable to write good programs in C. This time is so long, that there is a generation change already happening, which means that those who have perhaps learned something along the way, go to retirement and are replaced by new programmers who start afresh with zero experience and who are bound to repeat the same errors. That is, we are already at the maximum of what is possible and if we want some improvement, we need to improve the tools. > You're assuming that C is a broken tool. I don't think it is broken. I > just think it's a *powerful* tool, and as such needs careful handling. We have *decades* of evidence that careful handling of this tool is not happening and, taking into account the above, there is no reason to believe that it will begin to happen. Which might mean that we really need safer tools. -- Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 00:39 +0000 |
| Message-ID | <n1e8ce$mki$1@dont-email.me> |
| In reply to | #74881 |
On 04/11/15 22:11, see.my.homepage@gmail.com wrote:
>
>> Careful. I didn't carefully hide anything. It is true that having fewer
>> security flaws is a good thing. That does not imply ipso facto that
>> moving away from C will result in fewer security flaws. It might turn
>> out to mean that, but this hasn't been demonstrated.
>
> Yes, it was demonstrated, in many different ways.
I beg your pardon. I should have eschewed the passive voice. I meant
that you have not demonstrated it. But perhaps you're about to put that
right, so I'll read on.
> For example, at the low level, a language that does not allow
> (statically or dynamically) to overrun an array, will not have
> the vulnerabilities associated with overrunning of arrays and
> we know that many security flaws result from those.
Yes, I'll accept the point - but note that the cost is significant, as
we are now talking about enforced bounds-checking, even when the
programmer knows perfectly well that the bounds will not be violated.
For example, consider this code:
unsigned long freq[UCHAR_MAX + 1] = {0};
while((ch = getc(fp)) != EOF)
{
++freq[ch];
}
It is simply *not possible* for that code to overstep the bounds of the
array, and yet the overhead of bounds checking will be incurred, yes?
(If you disagree, I'd be fascinated to hear why.)
> Just getting rid of this single issue would improve software
> security in a way that would be certainly visible and appreciated.
Yes, you'd improve security somewhat, at a performance cost. Now, it
isn't difficult to imagine a scenario where security vulnerabilities are
not relevant (air-gapped computer with no wireless connectivity, in an
access-controlled room) but where performance is paramount - e.g. a
government having a crack at some poor sap's RSA key. Such an
application would very likely be written in C, and the users are not
going to thank you for slowing the program down by introducing
unnecessary bounds checking. (That isn't to say that bounds checking
doesn't have its place. But that place can be the test environment - it
doesn't have to be the production code.)
>> What's more,
>> although security is indeed very important, there are other very
>> important aspects of programming as well.
>
> Yes.
>
>> For example:
>> readability,
>
> C is one of the least readable languages ever invented.
Quite apart from the "hobbyist" languages (Brainf**k, Piet, Ook!,
Malbolge, INTERCAL, Befunge, and of course Whitespace, to name but a
few), what about Perl, APL, LISP, Pick PROC, Fortran...? You can't throw
a brick at a list of programming languages without hitting several dozen
that are less readable than C.
It is, of course, possible to write C that is hard to read, but that's
true of any programming language.
> The obfuscated C contest would not be established without this property.
The reason they don't have an obfuscated APL contest is that /all/ APL
programs are obfuscated. The IOCCC is supposed to be a bit of fun, and
also a gentle reminder that this is *not* the right way to write C code.
>
>> correctness,
>
> C does not provide any correctness-oriented tools for the programmer.
I don't think I claimed it did. My point was that security is not the
only criterion by which we measure a program.
>
>> performance, portability,
>
> It is possible to achieve them without compromising security.
If you increase the amount of work the computer has to carry out on
operations that are not part of the algorithm (which, for example,
bounds-checking necessarily does), then that program will run more
slowly than if you don't.
I mentioned portability only as another aspect of a program that has to
be taken into account - i.e. that security is not the be all and end all
of computer programming.
I am not saying security is unimportant. Of course it's important. It's
just that there are other important things, too.
>> flexibility,
>
> What does that mean?
Take bounds-checking, for example. If you take responsibility for doing
it yourself, you can leave it out when you know you don't need it.
>
>> and
>> (often) even the familiarity of the project team with the language.
>
> But you have just stated that people in general do not get it, so why "familiarity" is an argument?
Do you not think that, all else being equal, people will write more
secure programs in a language they know well than in a language they
don't know well? Anyway, my point was that these are some of the reasons
some people select a programming language, and those reasons may or may
not trump security considerations (which is not to say that secure
programming techniques should be ignored or abandoned).
>
>> There are undoubtedly ways of using C
>> that lead to security vulnerabilities, but that's true of any language.
>> That is, for any language you care to name, I can come up with a
>> security vulnerability that it would be possible to perpetrate in that
>> language.
>
> It does not matter. The problem with security vulnerabilities is that
> they are easy to fall into - unwillingly. Any other language that
> makes it harder to do insecure things (like overruning the array)
> would be better, because, statistically speaking, programmers would
> fall into them less often.
Again, you are touting security as the sine qua non. I'm not saying it's
unimportant. I'm saying other things are important too.
> The idea is to make it harder to make errors, not to make it entirely impossible.
That's a worthy goal. So is performance.
> In other words, by selecting from the intentionally limited
> set of options, you have again fell into the same logic trap as before.
You appear to be operating on the assumption that security trumps
everything else. It's important, and in some situations (eg the
Heartbeat fiasco) it's *really* important, but there are other
considerations too. If you want a B&D language, there are plenty to
choose from. C's strength is in performance. There is lots of room in
this life for more than one programming language, and each has its own
strengths and weaknesses. Choosing a language intelligently is an
exercise in matching the project requirements against those strengths
and weaknesses.
>> (That is, it is easily possible to come up with a security
>> vulnerability in an *algorithm*, in which case any language that
>> faithfully implements the algorithm will faithfully implement the
>> vulnerability too.)
>
> Great idea. Let take some security-related algorithm as an example:
>
> http://www.adacore.com/press/spark-skein/
If I understand that correctly, it works roughly like this:
Inputs: x and y are two 64-bit words
x += y;
y <<<= k;
y ^= x;
Outputs: x and y (lather, rinse, repeat)
>
> "It is stunning how the formal verification of the SPARK source code actually made us discover a flaw in our own reference C implementation."
Okay, I'll believe you. Now let's take another algorithm as an example
of what I actually had in mind:
Implementing a One-Time Pad
---------------------------
Alice and Bob share a one-octet key. The first character is enciphered
with this octet. For all subsequent characters, the middle four bits are
now taken (if they are all 0, make it 1001) and squared, giving the key
for the next character. (Again, lather, rinse, repeat.)
This so-called "one-time pad" (a simplified variant of the "one-time
pad" employed by the bad guys in a Tom Clancy novel) can of course be
hacked by brute force in just a tiny handful of iterations.
Faithfully implement the algorithm in *any* language, no matter how
secure, and you faithfully implement a security weakness.
<At this point, I ran out of enthusiasm for what is proving to be a very
dull debate.>
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 01:15 +0000 |
| Message-ID | <87si4l1c29.fsf@bsb.me.uk> |
| In reply to | #74904 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 04/11/15 22:11, see.my.homepage@gmail.com wrote:
<snip>
>> For example, at the low level, a language that does not allow
>> (statically or dynamically) to overrun an array, will not have
>> the vulnerabilities associated with overrunning of arrays and
>> we know that many security flaws result from those.
>
> Yes, I'll accept the point - but note that the cost is significant, as
> we are now talking about enforced bounds-checking, even when the
> programmer knows perfectly well that the bounds will not be
> violated. For example, consider this code:
>
> unsigned long freq[UCHAR_MAX + 1] = {0};
> while((ch = getc(fp)) != EOF)
> {
> ++freq[ch];
> }
>
> It is simply *not possible* for that code to overstep the bounds of
> the array, and yet the overhead of bounds checking will be incurred,
> yes? (If you disagree, I'd be fascinated to hear why.)
In this case, the overhead could be at compiler time only because a C
compiler can prove that the array access is safe. It knows the set of
possible returns from getc, and the access is guarded to exclude the
only one that won't be valid as an index.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 02:02 +0000 |
| Message-ID | <n1ed78$49l$1@dont-email.me> |
| In reply to | #74907 |
On 05/11/15 01:15, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 04/11/15 22:11, see.my.homepage@gmail.com wrote:
> <snip>
>>> For example, at the low level, a language that does not allow
>>> (statically or dynamically) to overrun an array, will not have
>>> the vulnerabilities associated with overrunning of arrays and
>>> we know that many security flaws result from those.
>>
>> Yes, I'll accept the point - but note that the cost is significant, as
>> we are now talking about enforced bounds-checking, even when the
>> programmer knows perfectly well that the bounds will not be
>> violated. For example, consider this code:
>>
>> unsigned long freq[UCHAR_MAX + 1] = {0};
>> while((ch = getc(fp)) != EOF)
>> {
>> ++freq[ch];
>> }
>>
>> It is simply *not possible* for that code to overstep the bounds of
>> the array, and yet the overhead of bounds checking will be incurred,
>> yes? (If you disagree, I'd be fascinated to hear why.)
>
> In this case, the overhead could be at compiler time only because a C
> compiler can prove that the array access is safe. It knows the set of
> possible returns from getc, and the access is guarded to exclude the
> only one that won't be valid as an index.
Quite right. So let's move it on a stage further:
/* header */
#ifndef FREQ_H_
#define FREQ_H_ 1
#include <stdio.h>
void freqanalyse(unsigned long *freq, FILE *fp);
#endif
/* source 1 */
#include "freq.h"
void freqanalyse(unsigned long *freq, FILE *fp)
{
int ch;
while((ch = getc(fp)) != EOF)
{
++freq[ch];
}
}
/* source 2 */
#include "freq.h"
#include <limits.h>
unsigned long mostfrequent(unsigned char *mf,
unsigned long *freq,
FILE *fp)
{
unsigned long m = 0;
int i = 0;
freqanalyse(freq, fp);
for(i = 0; i < UCHAR_MAX + 1; i++)
{
if(freq[i] > m)
{
m = freq[i];
*mf = i;
}
}
return m;
}
The compiler cannot now know, when compiling Source 1, that the array
bounds are left inviolate by the code, because it doesn't know how long
the array is. (It is defined as UCHAR_MAX + 1 elements in some other
source. The programmer knows this, of course.)
In Source 2, the same applies. Furthermore, the compiler cannot know
that mf points to a valid unsigned char object. (The programmer does, of
course, know this, because he's got an unsigned char object whose
address he has passed to the function using &.)
So (absent an abnormally clever linker) a B&D compiler would have to
insert runtime bounds checks for Sources 1 and 2, *and* a pointer
validity check (essentially another bounds check) for the *mf deref in
Source 2 - and yet the programmer knows (or can easily find out just by
looking at, say, main()) that the checks are pointless.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-04 18:31 -0800 |
| Message-ID | <d859dda8-415a-4dbb-b99f-e5c29aa5cb72@googlegroups.com> |
| In reply to | #74911 |
On Wednesday, November 4, 2015 at 8:02:30 PM UTC-6, Richard Heathfield wrote: > The compiler cannot now know, when compiling Source 1, that the array > bounds are left inviolate by the code, because it doesn't know how long > the array is. (It is defined as UCHAR_MAX + 1 elements in some other > source. The programmer knows this, of course.) In Pascal, one could write the FreqAnalyze method to accept a reference to an Array256, which is in turn defined as "Array[0..255] Of Integer", in which case the compiler would have no problem knowing the size of the array. In C, it would be somewhat more awkward to let the recipient know that it's receiving a pointer to a 256-element array, but it's possible. > So (absent an abnormally clever linker) a B&D compiler would have to > insert runtime bounds checks for Sources 1 and 2, *and* a pointer > validity check (essentially another bounds check) for the *mf deref in > Source 2 - and yet the programmer knows (or can easily find out just by > looking at, say, main()) that the checks are pointless. The C language was never designed to facilitate optimization, and could really use some new directives to fill some of its shortcomings, but there is no reason why compilers could not use such directives to hoist bounds- checking out of time-critical loops, if such directives were defined.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 12:38 +0000 |
| Message-ID | <87fv0k1v0d.fsf@bsb.me.uk> |
| In reply to | #74911 |
Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> Quite right. So let's move it on a stage further:
>
> /* header */
> #ifndef FREQ_H_
> #define FREQ_H_ 1
> #include <stdio.h>
> void freqanalyse(unsigned long *freq, FILE *fp);
> #endif
>
> /* source 1 */
> #include "freq.h"
>
> void freqanalyse(unsigned long *freq, FILE *fp)
> {
> int ch;
> while((ch = getc(fp)) != EOF)
> {
> ++freq[ch];
> }
> }
<snip>
> The compiler cannot now know, when compiling Source 1, that the array
> bounds are left inviolate by the code, because it doesn't know how
> long the array is. (It is defined as UCHAR_MAX + 1 elements in some
> other source. The programmer knows this, of course.)
The programmer does not know this when examining the function in
question and that's an important point. Languages that are less of a
free-for-all allow one to argue that a function is correct without
needing to look elsewhere (including, importantly, into the future).
And if the programmer can easily argue about the correctness of a
function, the compiler stands a chance of being able to eliminate bounds
checks.
Even in C we can say what we mean:
void freqanalyse(unsigned long (*freq)[UCHAR_MAX + 1], FILE *fp)
{
int ch;
while((ch = getc(fp)) != EOF)
{
++(*freq)[ch];
}
}
so a clever compiler could eliminate bounds checking.
> /* source 2 */
> #include "freq.h"
> #include <limits.h>
>
> unsigned long mostfrequent(unsigned char *mf,
> unsigned long *freq,
> FILE *fp)
> {
> unsigned long m = 0;
> int i = 0;
> freqanalyse(freq, fp);
> for(i = 0; i < UCHAR_MAX + 1; i++)
> {
> if(freq[i] > m)
> {
> m = freq[i];
> *mf = i;
> }
> }
> return m;
> }
There are two interesting things here. First, why is the array not
being scanned up to it's known upper bound? Well, we know why --
because people don't like to write array pointer types, and the sizeof
array/sizeof array[0] idiom is so cumbersome -- even more so with a
pointer to the array.
But the second point is why is this code being written yet again? It's
2015. If someone had told me in 1980 that in 35 years time people would
still be writing functions to find the index of an array's maximum, I'd
have been astounded. C does not promote the writing, once and for all,
of generic algorithms, so people write code like this again and again
and again. Every time they do, there is another chance of a mistake.
> In Source 2, the same applies. Furthermore, the compiler cannot know
> that mf points to a valid unsigned char object. (The programmer does,
> of course, know this, because he's got an unsigned char object whose
> address he has passed to the function using &.)
>
> So (absent an abnormally clever linker) a B&D compiler would have to
> insert runtime bounds checks for Sources 1 and 2, *and* a pointer
> validity check (essentially another bounds check) for the *mf deref in
> Source 2 - and yet the programmer knows (or can easily find out just
> by looking at, say, main()) that the checks are pointless.
Even in C, there is no need to pass a pointer to mostfrequent because
the caller is passing the frequency array. If you need more than the
index of the maximum, it's a simple x[max] expression.
But I don't want to miss your point in a detail like this. Yes, you are
right that C offers very little help to eliminate bound and pointer
checks. The cost of it in C is particularly high.
Of course it's not zero even in languages specifically designed for it,
but isn't using C "for speed" one of those premature optimisations we
are so often being told to avoid? How often is C used when a less
error-prone alternative would be fast enough? I'm not suggesting this
is a straight parallel -- when you find you need an optimisation, you
can add it, but when you find your chosen language is too slow you have
to do a full re-write -- but I suspect that C is used "for speed" in
quite a few cases where the speed of an alternative would not be an
issue.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-04 18:24 -0800 |
| Message-ID | <8fc4438a-bdf9-4dd6-977c-0cb0d28e64c2@googlegroups.com> |
| In reply to | #74904 |
On Wednesday, November 4, 2015 at 6:40:07 PM UTC-6, Richard Heathfield wrote:
> It is simply *not possible* for that code to overstep the bounds of the
> array, and yet the overhead of bounds checking will be incurred, yes?
> (If you disagree, I'd be fascinated to hear why.)
Compilers which bundle their own getc() routine may be able to determine the
range of values it can produce. Those which rely upon a getc() routine taken
from elsewhere should expect that it might behave in "interesting" fashion
and be prepared for that possibility. A programmer who's concerned about
speed could write `++freq[(unsigned char)ch]`, in which case compilers would
be able to recognize that the result was guaranteed to be in bounds.
Besides, many languages which include bounds-checking also provide means by
which it can be disabled within narrow contexts. Since most programs spend
the vast majority of their time in a few critical loops, checking pre-
conditions outside such loop and then letting the loops run without internal
bounds-checking, but enabling bounds-checking everywhere else, will be easier
than manually-bounds-checking everything but essentially as fast as not using
any automatic bounds-checking.
Further, modern versions of Java are able to hoist boounds checking out of
many loops even without the ability to disable array-bounds checking, and
I see no reason a C compiler couldn't do likewise.
> Yes, you'd improve security somewhat, at a performance cost. Now, it
> isn't difficult to imagine a scenario where security vulnerabilities are
> not relevant (air-gapped computer with no wireless connectivity, in an
> access-controlled room) but where performance is paramount - e.g. a
> government having a crack at some poor sap's RSA key. Such an
> application would very likely be written in C, and the users are not
> going to thank you for slowing the program down by introducing
> unnecessary bounds checking. (That isn't to say that bounds checking
> doesn't have its place. But that place can be the test environment - it
> doesn't have to be the production code.)
There's nothing wrong with a language providing a means of disabling bounds-
checking if it's not expected to "sandbox" code. On the other hand, since
most programs spend the vast majority of their time executing a tiny portion
of the code, it would generally make sense to have array bounds checking
enabled by default except in a few speed-critical routines (and even there,
one might still leave bounds-checking enabled unless the compiler isn't able
to automatically hoist it).
> If you increase the amount of work the computer has to carry out on
> operations that are not part of the algorithm (which, for example,
> bounds-checking necessarily does), then that program will run more
> slowly than if you don't.
Ironically, modern compilers in the name of "optimization", have often
increased the amount of work programmers have to do to avoid having newer
compilers trash code which older compilers handled in useful fashion even
though the Standard didn't require it. Consider, for example, how one would
write a function with the following specification [assume "int" is 32 bits]
int foo(int x);
If x is less than 50000 perform some operation based upon x, otherwise don't.
After that, if x is less than 1000 return x*x*x, else return any number.
Historically, it would have been possible on 99% of C compilers where int
is 32 bits to write the function as:
int foo(int x)
{
if (x < 50000) perform_some_operation(x);
return x*x*x;
}
and have it work perfectly. Hyper-modern compilers will realize, however,
that if x is greater than 1290 they are allowed by the Standard to do
anything, including call "perform_some_operation" with values of x greater
than 50000. In order for code to avoid that, it must add extra logic to
either ensure that values greater than 1290 aren't cubed or else convert x
to a larger type before cubing. Depending upon how that extra code is
written, an optimizer may or may not be able to eliminate it.
> I mentioned portability only as another aspect of a program that has to
> be taken into account - i.e. that security is not the be all and end all
> of computer programming.
>
> I am not saying security is unimportant. Of course it's important. It's
> just that there are other important things, too.
Unfortunately, the C Standard is hostile to portability, because it fails to
acknowledge the existence of many features which are present in real-world
implementations and are needed to efficiently satisfy many real-world
application requirements.
> Take bounds-checking, for example. If you take responsibility for doing
> it yourself, you can leave it out when you know you don't need it.
Or if you're using e.g. Turbo Pascal, you write {$R-} before code that you
know doesn't need bounds-checking, and {$R+} after.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-04 19:37 -0800 |
| Message-ID | <lnoaf95d68.fsf@kst-u.example.com> |
| In reply to | #74913 |
supercat@casperkitty.com writes:
> On Wednesday, November 4, 2015 at 6:40:07 PM UTC-6, Richard Heathfield wrote:
>> It is simply *not possible* for that code to overstep the bounds of the
>> array, and yet the overhead of bounds checking will be incurred, yes?
>> (If you disagree, I'd be fascinated to hear why.)
>
> Compilers which bundle their own getc() routine may be able to determine the
> range of values it can produce. Those which rely upon a getc() routine taken
> from elsewhere should expect that it might behave in "interesting" fashion
> and be prepared for that possibility. A programmer who's concerned about
> speed could write `++freq[(unsigned char)ch]`, in which case compilers would
> be able to recognize that the result was guaranteed to be in bounds.
The behavior of getc() is defined by the standard library, so a compiler
may assume that it behaves as specified (i.e., that it returns a value
that either is equal to EOF or is in the range 0..UCHAR_MAX).
Replacing getc() by a function that doesn't behave as the standard
requires causes undefined behavior if it's done by the programmer, or
non-conformance if it's done by the implementation.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-05 13:24 +0100 |
| Message-ID | <n1fhkr$9nd$1@dont-email.me> |
| In reply to | #74913 |
On 05/11/15 03:24, supercat@casperkitty.com wrote:
> On Wednesday, November 4, 2015 at 6:40:07 PM UTC-6, Richard Heathfield wrote:
>> It is simply *not possible* for that code to overstep the bounds of the
>> array, and yet the overhead of bounds checking will be incurred, yes?
>> (If you disagree, I'd be fascinated to hear why.)
>
> Compilers which bundle their own getc() routine may be able to determine the
> range of values it can produce. Those which rely upon a getc() routine taken
> from elsewhere should expect that it might behave in "interesting" fashion
> and be prepared for that possibility. A programmer who's concerned about
> speed could write `++freq[(unsigned char)ch]`, in which case compilers would
> be able to recognize that the result was guaranteed to be in bounds.
>
> Besides, many languages which include bounds-checking also provide means by
> which it can be disabled within narrow contexts. Since most programs spend
> the vast majority of their time in a few critical loops, checking pre-
> conditions outside such loop and then letting the loops run without internal
> bounds-checking, but enabling bounds-checking everywhere else, will be easier
> than manually-bounds-checking everything but essentially as fast as not using
> any automatic bounds-checking.
>
> Further, modern versions of Java are able to hoist boounds checking out of
> many loops even without the ability to disable array-bounds checking, and
> I see no reason a C compiler couldn't do likewise.
>
>
>> Yes, you'd improve security somewhat, at a performance cost. Now, it
>> isn't difficult to imagine a scenario where security vulnerabilities are
>> not relevant (air-gapped computer with no wireless connectivity, in an
>> access-controlled room) but where performance is paramount - e.g. a
>> government having a crack at some poor sap's RSA key. Such an
>> application would very likely be written in C, and the users are not
>> going to thank you for slowing the program down by introducing
>> unnecessary bounds checking. (That isn't to say that bounds checking
>> doesn't have its place. But that place can be the test environment - it
>> doesn't have to be the production code.)
>
> There's nothing wrong with a language providing a means of disabling bounds-
> checking if it's not expected to "sandbox" code. On the other hand, since
> most programs spend the vast majority of their time executing a tiny portion
> of the code, it would generally make sense to have array bounds checking
> enabled by default except in a few speed-critical routines (and even there,
> one might still leave bounds-checking enabled unless the compiler isn't able
> to automatically hoist it).
>
>> If you increase the amount of work the computer has to carry out on
>> operations that are not part of the algorithm (which, for example,
>> bounds-checking necessarily does), then that program will run more
>> slowly than if you don't.
>
> Ironically, modern compilers in the name of "optimization", have often
> increased the amount of work programmers have to do to avoid having newer
> compilers trash code which older compilers handled in useful fashion even
> though the Standard didn't require it. Consider, for example, how one would
> write a function with the following specification [assume "int" is 32 bits]
>
> int foo(int x);
>
> If x is less than 50000 perform some operation based upon x, otherwise don't.
> After that, if x is less than 1000 return x*x*x, else return any number.
How often do you see a specification like that, that explicitly says
"return any
>
> Historically, it would have been possible on 99% of C compilers where int
> is 32 bits to write the function as:
>
> int foo(int x)
> {
> if (x < 50000) perform_some_operation(x);
> return x*x*x;
> }
int foo(int x)
{
if (x < 50000) perform_some_operation(x);
if (x < 1000) return x*x*x;
return 0;
}
Writing code correctly is not /that/ hard.
>
> and have it work perfectly. Hyper-modern compilers will realize, however,
> that if x is greater than 1290 they are allowed by the Standard to do
> anything, including call "perform_some_operation" with values of x greater
> than 50000. In order for code to avoid that, it must add extra logic to
> either ensure that values greater than 1290 aren't cubed or else convert x
> to a larger type before cubing. Depending upon how that extra code is
> written, an optimizer may or may not be able to eliminate it.
Do you have any indication that any compilers make these kinds of
optimisations? Annex L would, I believe disallow them (unless the
compiler knows the definition of "perform_some_operation" and knows it
is safe) - if "perform_some_operation" does something disallowed by
"bounded undefined behaviour", then the code can't call it just because
x*x*x overflows. But even without Annex L, I don't see such things
being likely. Compilers don't go out of their way to cause problems or
confusion for their users.
>
>> I mentioned portability only as another aspect of a program that has to
>> be taken into account - i.e. that security is not the be all and end all
>> of computer programming.
>>
>> I am not saying security is unimportant. Of course it's important. It's
>> just that there are other important things, too.
>
> Unfortunately, the C Standard is hostile to portability, because it fails to
> acknowledge the existence of many features which are present in real-world
> implementations and are needed to efficiently satisfy many real-world
> application requirements.
>
>> Take bounds-checking, for example. If you take responsibility for doing
>> it yourself, you can leave it out when you know you don't need it.
>
> Or if you're using e.g. Turbo Pascal, you write {$R-} before code that you
> know doesn't need bounds-checking, and {$R+} after.
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-05 06:47 -0800 |
| Message-ID | <5003ccb8-54a9-43d2-b5e8-6d1555892722@googlegroups.com> |
| In reply to | #74950 |
On Thursday, November 5, 2015 at 6:24:25 AM UTC-6, David Brown wrote:
> On 05/11/15 03:24, supercat wrote:
> > If x is less than 50000 perform some operation based upon x, otherwise don't.
> > After that, if x is less than 1000 return x*x*x, else return any number.
>
> How often do you see a specification like that, that explicitly says
> "return any
Pretty often, actually, in three common scenarios:
1. It is expected that some fraction of the input to a program could be
invalid and any output produced as a result of such input will be
meaningless, but the existence of invalid data should not interfere
with the correct processing of valid data. For example, a program may
accept as input a bunch of files that are mostly going to contain
graphics data encoded via some particular means. If something which is
supposed to be a .GIF file actually contains something else, it may be
desirable to have the output specifically indicate that the source was
not a .GIF file, but producing a file of arbitrary pixel data may also
be acceptable provided the processing of other .GIF files is not
affected.
2. It is sometimes possible to compute heuristics which may err in at least
one direction from the correct value without impairing the correctness of
algorithms using them, although correctly-performed heuristics will
improve the performance of other algorithms.
3. Some callers of a function will pay attention to the return value, and
some will ignore it, and computing a return value unconditionally that
will be meaningful in the cases where callers actually need it and
will be ignored in cases where it's not meaningful, may be cheaper than
trying to avoid computing the return value when it isn't necessary.
> > Historically, it would have been possible on 99% of C compilers where int
> > is 32 bits to write the function as:
> >
> > int foo(int x)
> > {
> > if (x < 50000) perform_some_operation(x);
> > return x*x*x;
> > }
>
> int foo(int x)
> {
> if (x < 50000) perform_some_operation(x);
> if (x < 1000) return x*x*x;
> return 0;
You have added code which will likely make the program run slower on the
vast majority of compilers in the x<1290 case, and which will on many
compilers serve no useful purpose toward meeting requirements.
> Writing code correctly is not /that/ hard.
This example was contrived in a way that made it easy to identify the problem
cases. Many others aren't quite so nice. Let me offer another example:
int maxdiff(int *p1, int *p2, int n);
Find the largest difference p1[i]-p2[i] for 0<=i<n if all differences
are representable as "int". Return an arbitrary value if any difference
is not thus representable.
Seems simple, but there's no single way to write the code which will not on
at least some platforms take at least 50% longer than the optimal code for
those platforms. Some platforms can actually compute "(long)x-y > z" much
faster than they can compute "(int)((long)x-y) > z", and given a function
like the above the speed difference could be sufficient to have a major
effect on overall execution time.
> Do you have any indication that any compilers make these kinds of
> optimisations? Annex L would, I believe disallow them (unless the
> compiler knows the definition of "perform_some_operation" and knows it
> is safe) - if "perform_some_operation" does something disallowed by
> "bounded undefined behaviour", then the code can't call it just because
> x*x*x overflows. But even without Annex L, I don't see such things
> being likely. Compilers don't go out of their way to cause problems or
> confusion for their users.
Compilers which define __STDC_ANALYZABLE would not be allowed to make the
described optimization, but those which don't would be free to do so and
while I haven't tried the exact code above, it is in line with the kinds
of optimizations that some compiler writers consider fairly routine.
Note that the compiler writer doesn't need to know anything at all about
what "perform_some_operation" does in order to call it unconditionally.
If the sense of the test had been reversed, a compiler writer would not
be able to omit the call to "perform_some_operation" when x is greater
than 50000 without being able to prove that the function would always
return, but as written all possible execution paths where the function is
invoked with "x" being 50000 or greater would invoke Undefined Behavior, so
the Standard imposes no requirements on any of them.
[toc] | [prev] | [next] | [standalone]
| From | see.my.homepage@gmail.com |
|---|---|
| Date | 2015-11-05 00:35 -0800 |
| Message-ID | <5b9a2e66-305a-4a36-8df2-fde8f4078066@googlegroups.com> |
| In reply to | #74904 |
> For example, consider this code:
>
> unsigned long freq[UCHAR_MAX + 1] = {0};
> while((ch = getc(fp)) != EOF)
> {
> ++freq[ch];
> }
Others have already explained why it is trivial for the compiler to prove that bounds checking is not necessary here (and will therefore not involve any performance penalty).
Others have already explained why your example with separate functions unintentionally demonstrates the lack of support for correct programming in C. The C language does not even have proper concept of arrays. Your example is not a justification for omitting bounds checking. Any language that supports proper arrays would handle your example, and would do so safely, without incurring any performance penalty. You can have both safety and performance if you want.
> Yes, you'd improve security somewhat, at a performance cost.
You did not show that any performance cost needs to be paid.
> If you increase the amount of work the computer has to carry out on
> operations that are not part of the algorithm (which, for example,
> bounds-checking necessarily does), then that program will run more
> slowly than if you don't.
Unless you will move this effort to the compilation phase, in which case there will be no performance penalty at run time. But you need a better language for that.
> >> flexibility,
> >
> > What does that mean?
>
> Take bounds-checking, for example. If you take responsibility for doing
> it yourself, you can leave it out when you know you don't need it.
I prefer to have it the other way round - I want safe to be the default and I want unsafe to require significant effort from the programmer. This makes errors less probable and also highlights those parts of the code that deserve attention in terms of deeper review, testing, etc.
The problem with C is that it makes unsafe the default and requires effort to get the safety. This is entirely wrong.
> Do you not think that, all else being equal, people will write more
> secure programs in a language they know well than in a language they
> don't know well?
We have decades of evidence that people who (think that they) know C very well write bugs that would not be even possible (like array overruns) in those languages that make it impossible by construction, even for those programmers that do not know the language very well.
Another interesting evidence:
http://archive.adaic.com/projects/atwork/trains.html
This is the story of a university professor who found that after replacing C with something else his students were more likely to complete their projects properly. Scroll down to the "Software" part for shorter version.
> Again, you are touting security as the sine qua non. I'm not saying it's
> unimportant. I'm saying other things are important too.
By security I mean general correctness, without which computer programs are somewhere between useless and downright dangerous.
> > The idea is to make it harder to make errors, not to make it entirely impossible.
>
> That's a worthy goal. So is performance.
Let's have both, then. But for this, we need better tools.
> <At this point, I ran out of enthusiasm for what is proving to be a very
> dull debate.>
--
Maciej Sobczak * http://www.inspirel.com
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-05 09:55 +0000 |
| Message-ID | <n1f8v6$b91$1@dont-email.me> |
| In reply to | #74930 |
On 05/11/15 08:35, see.my.homepage@gmail.com wrote:
>
>> For example, consider this code:
>>
>> unsigned long freq[UCHAR_MAX + 1] = {0};
>> while((ch = getc(fp)) != EOF)
>> {
>> ++freq[ch];
>> }
>
> Others have already explained why it is trivial for the compiler
> to prove that bounds checking is not necessary here (and will
> therefore not involve any performance penalty).
Well, no, it's not trivial. I would certainly agree that it's possible,
though, which is why I posted another example.
> Others have already explained why your example with separate
> functions unintentionally demonstrates the lack of support
> for correct programming in C.
Have they now? I've seen SuperCat's response, whch doesn't seem to me to
explain anything of the kind. If there are any other responses, I
haven't seen them.
What I have seen, however, is that you're determined to find C wanting,
and will twist any meaning to that end. I don't have a problem with
that, of course. But if you want Ada, you know where to find it.
> The C language does not even have proper concept of arrays.
But when you say something as ludicrous as that, I stop listening.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web