Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #56833 > unrolled thread
| Started by | Ted Lee <tmplee@gmail.com> |
|---|---|
| First post | 2014-02-22 12:56 -0600 |
| Last post | 2014-03-01 21:53 +0000 |
| Articles | 20 on this page of 197 — 21 participants |
Back to article view | Back to comp.sys.mac.system
Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-22 12:56 -0600
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 14:15 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:47 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:30 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:04 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 00:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 09:48 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:41 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 12:05 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 17:22 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:15 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 03:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:25 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:16 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:50 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 07:51 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:23 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:01 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:21 +0000
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 04:35 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 16:52 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-24 21:54 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:44 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:26 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:46 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:43 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:40 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:45 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-25 00:57 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 05:04 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 06:00 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 16:10 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-24 12:15 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:47 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-25 13:41 +0000
Re: Latest IOS/OS X SSL security flaw Kurt Ullman <kurtullman@yahoo.com> - 2014-02-25 09:06 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 17:34 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 19:14 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:42 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:32 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:12 -0600
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 17:24 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:38 +0000
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-25 21:03 -0600
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:19 +0000
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-28 11:29 -0500
Re: Latest IOS/OS X SSL security flaw Ted Lee <tmplee@gmail.com> - 2014-02-28 12:48 -0600
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 01:44 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 21:59 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 22:33 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:13 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:45 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 23:17 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:28 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 23:16 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:17 -0800
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:03 +0100
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 21:00 +0100
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 22:02 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:11 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 16:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-25 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:45 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-25 20:57 +0100
Re: Latest IOS/OS X SSL security flaw "M. John Matlaw" <nouser@invalid.com> - 2014-02-26 09:52 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:36 +0200
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:24 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 20:43 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:40 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:47 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 15:37 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 20:08 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:15 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 18:45 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 02:52 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-23 19:01 -0800
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:23 +0000
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:10 +0100
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 22:21 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 17:27 -0500
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-24 21:05 -0800
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:34 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 21:58 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:04 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-25 02:44 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:14 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-24 04:11 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:36 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 08:20 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 17:00 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-25 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-25 21:31 +0000
Re: Latest IOS/OS X SSL security flaw Don Bruder <dakidd@sonic.net> - 2014-02-25 19:13 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 04:35 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-26 06:42 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:57 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:29 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:06 -0400
Re: Latest IOS/OS X SSL security flaw Tom Stiller <clusterfux.upmon@gmail.com> - 2014-04-13 21:11 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-15 17:03 -0400
Re: Latest IOS/OS X SSL security flaw Your Name <YourName@YourISP.com> - 2014-04-16 09:29 +1200
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:29 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 00:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:59 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 02:03 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 22:13 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-26 14:03 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:03 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:47 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-26 00:10 -0500
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:11 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:43 -0400
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-26 02:42 +0000
Re: Latest IOS/OS X SSL security flaw Walter Bushell <proto@panix.com> - 2014-04-13 15:08 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:41 -0400
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-25 19:18 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-26 23:39 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-27 17:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:03 -0500
Re: Latest IOS/OS X SSL security flaw Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2014-02-23 01:32 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:07 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-04-06 02:44 +0200
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:49 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:07 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 22:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 03:49 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:12 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:42 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:11 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw Jim Gibson <jimsgibson@gmail.com> - 2014-02-24 10:42 -0800
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-24 17:07 -0500
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 23:01 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:38 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:46 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:52 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-03-02 00:05 -0500
Re: Latest IOS/OS X SSL security flaw Paul Sture <nospam@sture.ch> - 2014-02-24 22:24 +0100
Re: Latest IOS/OS X SSL security flaw mcarels@xs4all.nl (Maarten Carels) - 2014-02-24 10:43 +0100
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 18:39 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-24 19:16 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:18 -0500
Re: Latest IOS/OS X SSL security flaw Tim McNamara <timmcn@bitstream.net> - 2014-02-22 13:43 -0600
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 14:52 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 20:05 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 15:16 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 21:10 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 16:25 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-22 22:13 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:19 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 18:55 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 09:38 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:17 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 15:42 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 10:45 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 17:09 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 13:51 -0500
Re: Latest IOS/OS X SSL security flaw Richard Kettlewell <rjk@greenend.org.uk> - 2014-02-23 20:07 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:14 -0500
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 15:20 -0500
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 02:18 +0000
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 17:51 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:55 -0500
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:50 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 19:09 -0500
Re: Latest IOS/OS X SSL security flaw Alan Baker <alangbaker@telus.net> - 2014-02-22 12:35 -0800
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 16:59 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 22:14 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 17:53 -0500
Re: Latest IOS/OS X SSL security flaw JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-02-22 18:01 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:22 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-22 18:29 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-22 23:33 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:08 +0000
Re: Latest IOS/OS X SSL security flaw Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:49 +0000
Re: Latest IOS/OS X SSL security flaw Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-02-22 22:57 -0800
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 16:36 +0000
Re: Latest IOS/OS X SSL security flaw Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-23 11:58 -0500
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 14:35 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-23 21:03 +0000
Re: Latest IOS/OS X SSL security flaw nospam <nospam@nospam.invalid> - 2014-02-23 18:23 -0500
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-02-24 01:07 +0000
Re: Latest IOS/OS X SSL security flaw billy@MIX.COM - 2014-02-24 01:53 +0000
Re: Latest IOS/OS X SSL security flaw Jolly Roger <jollyroger@pobox.com> - 2014-03-01 21:53 +0000
Page 1 of 10 [1] 2 3 … 10 Next page →
| From | Ted Lee <tmplee@gmail.com> |
|---|---|
| Date | 2014-02-22 12:56 -0600 |
| Subject | Latest IOS/OS X SSL security flaw |
| Message-ID | <lears8$l8d$1@dont-email.me> |
The press and gossip rag reports say the recently discovered security flaw with SSL is present in both IOS and OS X. The patch for IOS showed up last night. The reports say the OS X one will be out soon. Has anyone run across a technically competent (as opposed to sensationalized fear-mongering amateur drivel) discussion of the flaw *and* a conclusive statement that it is indeed present in OS X? Given Apple's policy of not discussing or acknowledging security flaws until a patch is available, I have to wonder if the flaw is in fact present in OS X -- for, if it were, wouldn't they wait to release anything (including a fix) about it until the patch was available for both? -- Ted
[toc] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2014-02-22 14:15 -0500 |
| Message-ID | <220220141415089899%nospam@nospam.invalid> |
| In reply to | #56833 |
In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com> wrote: > The press and gossip rag reports say the recently discovered security > flaw with SSL is present in both IOS and OS X. The patch for IOS showed > up last night. The reports say the OS X one will be out soon. Has > anyone run across a technically competent (as opposed to sensationalized > fear-mongering amateur drivel) discussion of the flaw *and* a conclusive > statement that it is indeed present in OS X? it is in os x, and it's nothing more than an extra goto. <https://www.imperialviolet.org/2014/02/22/applebug.html>
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-22 14:47 -0500 |
| Message-ID | <2NWdnQXy6oxRY5XOnZ2dnUVZ_qSdnZ2d@giganews.com> |
| In reply to | #56834 |
On 2014.02.22, 14:15 , nospam wrote:
> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
> wrote:
>
>> The press and gossip rag reports say the recently discovered security
>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>> up last night. The reports say the OS X one will be out soon. Has
>> anyone run across a technically competent (as opposed to sensationalized
>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>> statement that it is indeed present in OS X?
>
> it is in os x, and it's nothing more than an extra goto.
>
> <https://www.imperialviolet.org/2014/02/22/applebug.html>
ROFL.
goto has always been a source of low software quality - and it rears its
head again here - although it looks more like sloppy editing than
anything else - like another line of condition code had been deleted or
moved.
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-22 21:30 +0000 |
| Message-ID | <bmsj7oFmdpqU4@mid.individual.net> |
| In reply to | #56837 |
On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.22, 14:15 , nospam wrote: >> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com> >> wrote: >> >>> The press and gossip rag reports say the recently discovered security >>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed >>> up last night. The reports say the OS X one will be out soon. Has >>> anyone run across a technically competent (as opposed to sensationalized >>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive >>> statement that it is indeed present in OS X? >> >> it is in os x, and it's nothing more than an extra goto. >> >> <https://www.imperialviolet.org/2014/02/22/applebug.html> > > ROFL. > > goto has always been a source of low software quality - and it rears its > head again here - although it looks more like sloppy editing than > anything else - like another line of condition code had been deleted or > moved. Indeed. And as John Gruber (Daring Fireball) asserted, the practice of using curly braces for if blocks would have made the slip-up much more obvious. I tend to prefer using braces in if blocks myself. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-22 19:04 -0500 |
| Message-ID | <L-SdnavB-Z27ppTOnZ2dnUVZ_uKdnZ2d@giganews.com> |
| In reply to | #56849 |
On 2014.02.22, 16:30 , Jolly Roger wrote:
> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.22, 14:15 , nospam wrote:
>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>> wrote:
>>>
>>>> The press and gossip rag reports say the recently discovered security
>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>> up last night. The reports say the OS X one will be out soon. Has
>>>> anyone run across a technically competent (as opposed to sensationalized
>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>> statement that it is indeed present in OS X?
>>>
>>> it is in os x, and it's nothing more than an extra goto.
>>>
>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>
>> ROFL.
>>
>> goto has always been a source of low software quality - and it rears its
>> head again here - although it looks more like sloppy editing than
>> anything else - like another line of condition code had been deleted or
>> moved.
>
> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
> using curly braces for if blocks would have made the slip-up much more
> obvious. I tend to prefer using braces in if blocks myself.
I tend to think curly braces suck as code block begin/ends. ;-)
{This was esp. so with dot matrix printers. We didn't have no fancy
colour editors either}
What the hell is the matter with nice fat, 0 code producing BEGIN END
statements, anyway?
Ada. Ah, Ada, why have you forsaken us and let C rule?
Confession: testing the new disk docks I made an elegance improvement in
my program (writes random data to the disk on the dock) and it caused a
bug - program wrote about 25,000 files of 64KB each before I caught it
(file names have a random string on the end). The error (not involving
goto) was however of similar lameness to the one in the code above.
OTOH, it's just quickly written code to torture test the docks and just
as quickly fixed.
Note: if the disk is encrypted I hit about 110 MB/s; non-encrypted 165
MB/s. I didn't think there would be that much of a hit on encrypted drives.
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 00:36 +0000 |
| Message-ID | <bmsu50Fnr6sU2@mid.individual.net> |
| In reply to | #56870 |
On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 16:30 , Jolly Roger wrote:
>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.22, 14:15 , nospam wrote:
>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>> wrote:
>>>>
>>>>> The press and gossip rag reports say the recently discovered security
>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>> statement that it is indeed present in OS X?
>>>>
>>>> it is in os x, and it's nothing more than an extra goto.
>>>>
>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>
>>> ROFL.
>>>
>>> goto has always been a source of low software quality - and it rears its
>>> head again here - although it looks more like sloppy editing than
>>> anything else - like another line of condition code had been deleted or
>>> moved.
>>
>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>> using curly braces for if blocks would have made the slip-up much more
>> obvious. I tend to prefer using braces in if blocks myself.
>
> I tend to think curly braces suck as code block begin/ends. ;-)
>
> {This was esp. so with dot matrix printers. We didn't have no fancy
> colour editors either}
>
> What the hell is the matter with nice fat, 0 code producing BEGIN END
> statements, anyway?
>
> Ada. Ah, Ada, why have you forsaken us and let C rule?
Right there with you. : ) I can appreciate shortened forms; but not so
much when they increase the likelihood of mistakes like this. Pascal had
BEGIN/END too.
> Confession: testing the new disk docks I made an elegance improvement in
> my program (writes random data to the disk on the dock) and it caused a
> bug - program wrote about 25,000 files of 64KB each before I caught it
> (file names have a random string on the end). The error (not involving
> goto) was however of similar lameness to the one in the code above.
> OTOH, it's just quickly written code to torture test the docks and just
> as quickly fixed.
Mistakes are made by even the very best programmers. You have lots of
good company. : )
> Note: if the disk is encrypted I hit about 110 MB/s; non-encrypted 165
> MB/s. I didn't think there would be that much of a hit on encrypted drives.
Interesting. FileVault2, or something else?
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 09:48 -0500 |
| Message-ID | <hr6dnVg19vu-l5fOnZ2dnUVZ_rKdnZ2d@giganews.com> |
| In reply to | #56874 |
On 2014.02.22, 19:36 , Jolly Roger wrote:
> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>> using curly braces for if blocks would have made the slip-up much more
>>> obvious. I tend to prefer using braces in if blocks myself.
>>
>> I tend to think curly braces suck as code block begin/ends. ;-)
>>
>> {This was esp. so with dot matrix printers. We didn't have no fancy
>> colour editors either}
>>
>> What the hell is the matter with nice fat, 0 code producing BEGIN END
>> statements, anyway?
>>
>> Ada. Ah, Ada, why have you forsaken us and let C rule?
>
> Right there with you. : ) I can appreciate shortened forms; but not so
> much when they increase the likelihood of mistakes like this. Pascal had
> BEGIN/END too.
Pascal is what I use now for gps/nav, photography related stuff, etc.
(Because I have so many units of proven code to rely on). At present I
can't assemble my .ASM files on the mac because the assembler syntax
(register symbol style) isn't what I used to use (MS or Borland assemblers).
OTOH, if I assemble in Fusion/windows, the .obj code is linkable under
OS X (Lightweight IDE). That surprised me... but the old assemblers
can't do the newer instructions of course...
I've tried hand coding some instructions with constant declarations but
I get trapped errors at run time - doing something wrong (I want to use
the new i7 random number gen). I'll just have to learn the new
assembler syntax I guess... time.
FreePasacal is sort of a mishmash of several Pascal styles, TurboPascal
and Delphi being dominant. (Even supports MS-DOS file operations on the
Mac...).
I haven't written C since the exam in 198x. (Well maybe a couple little
things).
>> Confession: testing the new disk docks I made an elegance improvement in
>> my program (writes random data to the disk on the dock) and it caused a
>> bug - program wrote about 25,000 files of 64KB each before I caught it
>> (file names have a random string on the end). The error (not involving
>> goto) was however of similar lameness to the one in the code above.
>> OTOH, it's just quickly written code to torture test the docks and just
>> as quickly fixed.
>
> Mistakes are made by even the very best programmers. You have lots of
> good company. : )
>
>> Note: if the disk is encrypted I hit about 110 MB/s; non-encrypted 165
>> MB/s. I didn't think there would be that much of a hit on encrypted drives.
>
> Interesting. FileVault2, or something else?
Filevault2. I guess it's much more than XORs...
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 16:41 +0000 |
| Message-ID | <bmuml6F59p1U2@mid.individual.net> |
| In reply to | #56888 |
On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 19:36 , Jolly Roger wrote:
>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>
>>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>>> using curly braces for if blocks would have made the slip-up much more
>>>> obvious. I tend to prefer using braces in if blocks myself.
>>>
>>> I tend to think curly braces suck as code block begin/ends. ;-)
>>>
>>> {This was esp. so with dot matrix printers. We didn't have no fancy
>>> colour editors either}
>>>
>>> What the hell is the matter with nice fat, 0 code producing BEGIN END
>>> statements, anyway?
>>>
>>> Ada. Ah, Ada, why have you forsaken us and let C rule?
>>
>> Right there with you. : ) I can appreciate shortened forms; but not so
>> much when they increase the likelihood of mistakes like this. Pascal had
>> BEGIN/END too.
>
> Pascal is what I use now for gps/nav, photography related stuff, etc.
> (Because I have so many units of proven code to rely on). At present I
> can't assemble my .ASM files on the mac because the assembler syntax
> (register symbol style) isn't what I used to use (MS or Borland assemblers).
>
> OTOH, if I assemble in Fusion/windows, the .obj code is linkable under
> OS X (Lightweight IDE). That surprised me... but the old assemblers
> can't do the newer instructions of course...
>
> I've tried hand coding some instructions with constant declarations but
> I get trapped errors at run time - doing something wrong (I want to use
> the new i7 random number gen). I'll just have to learn the new
> assembler syntax I guess... time.
>
> FreePasacal is sort of a mishmash of several Pascal styles, TurboPascal
> and Delphi being dominant. (Even supports MS-DOS file operations on the
> Mac...).
Interesting. I haven't tried to compile any of my Pascal stuff since
CodeWarrior for Mac died.
> I haven't written C since the exam in 198x. (Well maybe a couple little
> things).
Wow. Lucky you? : D
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.
JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 12:05 -0500 |
| Message-ID | <fvydnWW6YI_3t5fOnZ2dnUVZ_rWdnZ2d@giganews.com> |
| In reply to | #56899 |
On 2014.02.23, 11:41 , Jolly Roger wrote:
> Interesting. I haven't tried to compile any of my Pascal stuff since
> CodeWarrior for Mac died.
Lightweight IDE and fpc work well for simple programming (and that does
support TurboPascal units of course; linking externals (C, assembler,
etc.)). I do see people on lists referring to fpc under XCode but I
find that to be tedious for the straightforward stuff I do.
>> I haven't written C since the exam in 198x. (Well maybe a couple little
>> things).
>
> Wow. Lucky you? : D
I do have a project in mind that might make me write in C because I
can't find any libraries that will compile for Pascal that give me
direct access to devices on USB such as GPS. If I can compile a unit in
C and call that from Pascal, it would be ideal.
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-02-23 17:22 +0000 |
| Message-ID | <bmup2iF5utbU1@mid.individual.net> |
| In reply to | #56903 |
On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.23, 11:41 , Jolly Roger wrote: > >> Interesting. I haven't tried to compile any of my Pascal stuff since >> CodeWarrior for Mac died. > > Lightweight IDE and fpc work well for simple programming (and that does > support TurboPascal units of course; linking externals (C, assembler, > etc.)). I do see people on lists referring to fpc under XCode but I > find that to be tedious for the straightforward stuff I do. I'll have to give it a spin sometime. Thanks. : ) -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2014-02-24 02:15 +0000 |
| Message-ID | <leea0d$4jt$1@reader2.panix.com> |
| In reply to | #56903 |
Alan Browne <alan.browne@freelunchvideotron.ca> writes:
> I do have a project in mind that might make me write in C because I
> can't find any libraries that will compile for Pascal that give me
> direct access to devices on USB such as GPS. If I can compile a unit in
> C and call that from Pascal, it would be ideal.
Mixing Pascal, Fortran, and C with GCC
http://alignment.hep.brandeis.edu/Software/Mixing/Mixing_Manual.html
The [Sun] C++ - Pascal Interface
http://www.amath.unc.edu/sysadmin/DOC4.0/pascal/user_guide/pascalug_C++.doc.html
Et cetera.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-24 03:57 +0000 |
| Message-ID | <slrnlglgpg.fcb.g.kreme@amelia.local> |
| In reply to | #56888 |
In message <hr6dnVg19vu-l5fOnZ2dnUVZ_rKdnZ2d@giganews.com> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > I haven't written C since the exam in 198x. (Well maybe a couple little > things). I stopped writing in Pascal in 198x when I first saw this in a C program: while((c=getchar())!=EOF) And that was the death of Pascal. Granted, my plan to write a lot of C never really developed because of perl, perl cgis, html, and later PHP. But still... -- A marriage is always made up of two people who are prepared to swear that only the other one snores.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-24 18:25 -0500 |
| Message-ID | <FbWdndt-x-eeSJbOnZ2dnUVZ_rednZ2d@giganews.com> |
| In reply to | #56944 |
On 2014.02.23, 22:57 , Lewis wrote:
> In message <hr6dnVg19vu-l5fOnZ2dnUVZ_rKdnZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> I haven't written C since the exam in 198x. (Well maybe a couple little
>> things).
>
> I stopped writing in Pascal in 198x when I first saw this in a C
> program:
>
> while((c=getchar())!=EOF)
Pascal: Assuming the header is:
Repeat c := readkey until c = EOF;
Is much clearer than the 'clever' c code.
Your C example is one of a hundred reasons why the US DoD categorically
rejected C when it was looking for a new standard language to be the
last of all DoD computer languages.
(When the Ada project began, the US DoD had s/w // f/w systems in over
2000 languages and dialects ...).
We had contractual language from US DoD and some commercial aerospace
co's to develop only, and solely in Ada (with strict minimum of
assembler - and if possible only in the boot CSCI).
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-25 08:16 +0000 |
| Message-ID | <slrnlgokah.1jei.g.kreme@oswin.local> |
| In reply to | #57023 |
In message <FbWdndt-x-eeSJbOnZ2dnUVZ_rednZ2d@giganews.com> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.02.23, 22:57 , Lewis wrote: >> In message <hr6dnVg19vu-l5fOnZ2dnUVZ_rKdnZ2d@giganews.com> >> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >>> I haven't written C since the exam in 198x. (Well maybe a couple little >>> things). >> >> I stopped writing in Pascal in 198x when I first saw this in a C >> program: >> >> while((c=getchar())!=EOF) > Pascal: Assuming the header is: > Repeat c := readkey until c = EOF; > Is much clearer than the 'clever' c code. > Your C example is one of a hundred reasons why the US DoD categorically > rejected C when it was looking for a new standard language to be the > last of all DoD computer languages. that's no defense, the DoD loves Java and COBOL. > We had contractual language from US DoD and some commercial aerospace > co's to develop only, and solely in Ada (with strict minimum of > assembler - and if possible only in the boot CSCI). My brother does a fuckload of Java programming for the DoD in Java. -- showing snuffy is when Sesame Street jumped the shark
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-25 19:50 -0500 |
| Message-ID | <sMKdncUIIMmgp5DOnZ2dnUVZ_qednZ2d@giganews.com> |
| In reply to | #57057 |
On 2014.02.25, 03:16 , Lewis wrote:
> In message <FbWdndt-x-eeSJbOnZ2dnUVZ_rednZ2d@giganews.com>
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.23, 22:57 , Lewis wrote:
>>> In message <hr6dnVg19vu-l5fOnZ2dnUVZ_rKdnZ2d@giganews.com>
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>> I haven't written C since the exam in 198x. (Well maybe a couple little
>>>> things).
>>>
>>> I stopped writing in Pascal in 198x when I first saw this in a C
>>> program:
>>>
>>> while((c=getchar())!=EOF)
>
>> Pascal: Assuming the header is:
>
>> Repeat c := readkey until c = EOF;
>
>> Is much clearer than the 'clever' c code.
>
>> Your C example is one of a hundred reasons why the US DoD categorically
>> rejected C when it was looking for a new standard language to be the
>> last of all DoD computer languages.
>
> that's no defense, the DoD loves Java and COBOL.
Not sure about Java (in any context).
Guess who invented COBOL in the first place... lot's of legacy COBOL
code to maintain at DoD.
>> We had contractual language from US DoD and some commercial aerospace
>> co's to develop only, and solely in Ada (with strict minimum of
>> assembler - and if possible only in the boot CSCI).
>
> My brother does a fuckload of Java programming for the DoD in Java.
Ugh. Sorry to hear that.
But in weapons, platform, navigation systems (and much more) I doubt
there is any Java other than perhaps on non critical displays for
visiting VIP's... (Ada is usually mandated for systems).
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Don Bruder <dakidd@sonic.net> |
|---|---|
| Date | 2014-02-23 07:51 -0800 |
| Message-ID | <led5e1$4q9$1@dont-email.me> |
| In reply to | #56874 |
In article <bmsu50Fnr6sU2@mid.individual.net>,
Jolly Roger <jollyroger@pobox.com> wrote:
> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> > On 2014.02.22, 16:30 , Jolly Roger wrote:
> >> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >>> On 2014.02.22, 14:15 , nospam wrote:
> >>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> The press and gossip rag reports say the recently discovered security
> >>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
> >>>>> up last night. The reports say the OS X one will be out soon. Has
> >>>>> anyone run across a technically competent (as opposed to sensationalized
> >>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
> >>>>> statement that it is indeed present in OS X?
> >>>>
> >>>> it is in os x, and it's nothing more than an extra goto.
> >>>>
> >>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
> >>>
> >>> ROFL.
> >>>
> >>> goto has always been a source of low software quality - and it rears its
> >>> head again here - although it looks more like sloppy editing than
> >>> anything else - like another line of condition code had been deleted or
> >>> moved.
> >>
> >> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
> >> using curly braces for if blocks would have made the slip-up much more
> >> obvious. I tend to prefer using braces in if blocks myself.
I tend toward "overkill unto the verge of paranoia" when bracing
conditionals, for exactly that reason. Even though I'm quite aware that
"if (foo) bar(foo);" is perfectly valid code that'll compile without so
much as a hiccup, if I'm coding something that needs that sort of
construct, I'm most likely going to write it as
if (foo)
{
bar(foo);
}
else
{
// It's a bad idea to bar() a nil foo
}
specifically to negate even the possibility of getting bit by that type
of bug. Vertical space is cheap insurance :)
> > I tend to think curly braces suck as code block begin/ends. ;-)
> >
> > {This was esp. so with dot matrix printers. We didn't have no fancy
> > colour editors either}
> >
> > What the hell is the matter with nice fat, 0 code producing BEGIN END
> > statements, anyway?
> >
> > Ada. Ah, Ada, why have you forsaken us and let C rule?
>
> Right there with you. : ) I can appreciate shortened forms; but not so
> much when they increase the likelihood of mistakes like this. Pascal had
> BEGIN/END too.
What? Never heard of
#define BEGIN {
#define END }
?
:)
Years ago, those, and other similar "translation" macros, were exactly
how I transitioned from Pascal to C. Then one day I noticed that the C
must have "kicked in" - I'd been using "naked" C and forgetting to
bother setting up or #include-ing the #defines for a while without even
realizing it.
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 11:23 -0500 |
| Message-ID | <juidnXCqaaIYvZfOnZ2dnUVZ_rCdnZ2d@giganews.com> |
| In reply to | #56895 |
On 2014.02.23, 10:51 , Don Bruder wrote:
> In article <bmsu50Fnr6sU2@mid.individual.net>,
> Jolly Roger <jollyroger@pobox.com> wrote:
>
>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>> On 2014.02.22, 14:15 , nospam wrote:
>>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The press and gossip rag reports say the recently discovered security
>>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS showed
>>>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>>>> anyone run across a technically competent (as opposed to sensationalized
>>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a conclusive
>>>>>>> statement that it is indeed present in OS X?
>>>>>>
>>>>>> it is in os x, and it's nothing more than an extra goto.
>>>>>>
>>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>>>
>>>>> ROFL.
>>>>>
>>>>> goto has always been a source of low software quality - and it rears its
>>>>> head again here - although it looks more like sloppy editing than
>>>>> anything else - like another line of condition code had been deleted or
>>>>> moved.
>>>>
>>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>>> using curly braces for if blocks would have made the slip-up much more
>>>> obvious. I tend to prefer using braces in if blocks myself.
>
> I tend toward "overkill unto the verge of paranoia" when bracing
> conditionals, for exactly that reason. Even though I'm quite aware that
> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
> much as a hiccup, if I'm coding something that needs that sort of
> construct, I'm most likely going to write it as
> if (foo)
> {
> bar(foo);
> }
> else
> {
> // It's a bad idea to bar() a nil foo
> }
> specifically to negate even the possibility of getting bit by that type
> of bug. Vertical space is cheap insurance :)
Wouldn't even think of it in Pascal (or Ada, or...)
if foo then bar(foo); // proc call; foo can be changed
// if declared VAR in parameters.
(or) if foo then foo := bar(foo); // function call
Much more readable too.
Trouble happens in Pascal with: ( I assume C is the same ...)
if bar(foo) or booz(goo) then ...
If bar returns true then booz is not called (default). This can be
important if booz is maintaining some program state and was supposed to
be called at that point. pragmas can be used to force both expressions
to execute even if bar(foo) returned true. I prefer to code it so there
is no ambiguity in execution - or to the future code reader.
f := bar(foo); foo := f; {optional or later}
g := booz(goo); goo := g; { " " }
if f or g then ...
That assures that both functions get called. Is readable. Does not
depend on pragmas or a future programmer understanding/seeing that the
compiler is in default or full expression mode.
>>> I tend to think curly braces suck as code block begin/ends. ;-)
>>>
>>> {This was esp. so with dot matrix printers. We didn't have no fancy
>>> colour editors either}
>>>
>>> What the hell is the matter with nice fat, 0 code producing BEGIN END
>>> statements, anyway?
>>>
>>> Ada. Ah, Ada, why have you forsaken us and let C rule?
>>
>> Right there with you. : ) I can appreciate shortened forms; but not so
>> much when they increase the likelihood of mistakes like this. Pascal had
>> BEGIN/END too.
>
> What? Never heard of
> #define BEGIN {
> #define END }
> ?
> :)
Lipstick on a pig?
--
Those who have reduced our privacy, whether they are state
or commercial actors, prefer that we do not reduce theirs.
- Jaron Lanier, Scientific American, 2013.11.
[toc] | [prev] | [next] | [standalone]
| From | Don Bruder <dakidd@sonic.net> |
|---|---|
| Date | 2014-02-23 15:05 -0800 |
| Message-ID | <ledurc$p6s$1@dont-email.me> |
| In reply to | #56897 |
In article <juidnXCqaaIYvZfOnZ2dnUVZ_rCdnZ2d@giganews.com>,
Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.23, 10:51 , Don Bruder wrote:
> > In article <bmsu50Fnr6sU2@mid.individual.net>,
> > Jolly Roger <jollyroger@pobox.com> wrote:
> >
> >> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >>> On 2014.02.22, 16:30 , Jolly Roger wrote:
> >>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> >>>>> On 2014.02.22, 14:15 , nospam wrote:
> >>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> The press and gossip rag reports say the recently discovered security
> >>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS
> >>>>>>> showed
> >>>>>>> up last night. The reports say the OS X one will be out soon. Has
> >>>>>>> anyone run across a technically competent (as opposed to
> >>>>>>> sensationalized
> >>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a
> >>>>>>> conclusive
> >>>>>>> statement that it is indeed present in OS X?
> >>>>>>
> >>>>>> it is in os x, and it's nothing more than an extra goto.
> >>>>>>
> >>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
> >>>>>
> >>>>> ROFL.
> >>>>>
> >>>>> goto has always been a source of low software quality - and it rears
> >>>>> its
> >>>>> head again here - although it looks more like sloppy editing than
> >>>>> anything else - like another line of condition code had been deleted or
> >>>>> moved.
> >>>>
> >>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
> >>>> using curly braces for if blocks would have made the slip-up much more
> >>>> obvious. I tend to prefer using braces in if blocks myself.
> >
> > I tend toward "overkill unto the verge of paranoia" when bracing
> > conditionals, for exactly that reason. Even though I'm quite aware that
> > "if (foo) bar(foo);" is perfectly valid code that'll compile without so
> > much as a hiccup, if I'm coding something that needs that sort of
> > construct, I'm most likely going to write it as
> > if (foo)
> > {
> > bar(foo);
> > }
> > else
> > {
> > // It's a bad idea to bar() a nil foo
> > }
> > specifically to negate even the possibility of getting bit by that type
> > of bug. Vertical space is cheap insurance :)
>
> Wouldn't even think of it in Pascal (or Ada, or...)
>
> if foo then bar(foo); // proc call; foo can be changed
> // if declared VAR in parameters.
>
> (or) if foo then foo := bar(foo); // function call
>
> Much more readable too.
That would be one man's opinion. Personally, I find "one line
conditionals" less explicitly clear than the multi-line equivalent.
>
>
>
> Trouble happens in Pascal with: ( I assume C is the same ...)
>
> if bar(foo) or booz(goo) then ...
>
> If bar returns true then booz is not called (default). This can be
> important if booz is maintaining some program state and was supposed to
> be called at that point. pragmas can be used to force both expressions
> to execute even if bar(foo) returned true. I prefer to code it so there
> is no ambiguity in execution - or to the future code reader.
>
> f := bar(foo); foo := f; {optional or later}
> g := booz(goo); goo := g; { " " }
>
> if f or g then ...
>
> That assures that both functions get called. Is readable. Does not
> depend on pragmas or a future programmer understanding/seeing that the
> compiler is in default or full expression mode.
>
> >>> I tend to think curly braces suck as code block begin/ends. ;-)
> >>>
> >>> {This was esp. so with dot matrix printers. We didn't have no fancy
> >>> colour editors either}
> >>>
> >>> What the hell is the matter with nice fat, 0 code producing BEGIN END
> >>> statements, anyway?
> >>>
> >>> Ada. Ah, Ada, why have you forsaken us and let C rule?
> >>
> >> Right there with you. : ) I can appreciate shortened forms; but not so
> >> much when they increase the likelihood of mistakes like this. Pascal had
> >> BEGIN/END too.
> >
> > What? Never heard of
> > #define BEGIN {
> > #define END }
> > ?
> > :)
>
> Lipstick on a pig?
No, a simple way to get the "BEGIN" and "END" that some prefer.
(Although yes, I do agree that it's rather pointless once one is fluent
in the language)
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-02-23 20:01 -0500 |
| Message-ID | <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com> |
| In reply to | #56923 |
On 2014.02.23, 18:05 , Don Bruder wrote:
> In article <juidnXCqaaIYvZfOnZ2dnUVZ_rCdnZ2d@giganews.com>,
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>
>> On 2014.02.23, 10:51 , Don Bruder wrote:
>>> In article <bmsu50Fnr6sU2@mid.individual.net>,
>>> Jolly Roger <jollyroger@pobox.com> wrote:
>>>
>>>> On 2014-02-23, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>> On 2014.02.22, 16:30 , Jolly Roger wrote:
>>>>>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>>>>> On 2014.02.22, 14:15 , nospam wrote:
>>>>>>>> In article <lears8$l8d$1@dont-email.me>, Ted Lee <tmplee@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The press and gossip rag reports say the recently discovered security
>>>>>>>>> flaw with SSL is present in both IOS and OS X. The patch for IOS
>>>>>>>>> showed
>>>>>>>>> up last night. The reports say the OS X one will be out soon. Has
>>>>>>>>> anyone run across a technically competent (as opposed to
>>>>>>>>> sensationalized
>>>>>>>>> fear-mongering amateur drivel) discussion of the flaw *and* a
>>>>>>>>> conclusive
>>>>>>>>> statement that it is indeed present in OS X?
>>>>>>>>
>>>>>>>> it is in os x, and it's nothing more than an extra goto.
>>>>>>>>
>>>>>>>> <https://www.imperialviolet.org/2014/02/22/applebug.html>
>>>>>>>
>>>>>>> ROFL.
>>>>>>>
>>>>>>> goto has always been a source of low software quality - and it rears
>>>>>>> its
>>>>>>> head again here - although it looks more like sloppy editing than
>>>>>>> anything else - like another line of condition code had been deleted or
>>>>>>> moved.
>>>>>>
>>>>>> Indeed. And as John Gruber (Daring Fireball) asserted, the practice of
>>>>>> using curly braces for if blocks would have made the slip-up much more
>>>>>> obvious. I tend to prefer using braces in if blocks myself.
>>>
>>> I tend toward "overkill unto the verge of paranoia" when bracing
>>> conditionals, for exactly that reason. Even though I'm quite aware that
>>> "if (foo) bar(foo);" is perfectly valid code that'll compile without so
>>> much as a hiccup, if I'm coding something that needs that sort of
>>> construct, I'm most likely going to write it as
>>> if (foo)
>>> {
>>> bar(foo);
>>> }
>>> else
>>> {
>>> // It's a bad idea to bar() a nil foo
>>> }
>>> specifically to negate even the possibility of getting bit by that type
>>> of bug. Vertical space is cheap insurance :)
>>
>> Wouldn't even think of it in Pascal (or Ada, or...)
>>
>> if foo then bar(foo); // proc call; foo can be changed
>> // if declared VAR in parameters.
>>
>> (or) if foo then foo := bar(foo); // function call
>>
>> Much more readable too.
>
> That would be one man's opinion. Personally, I find "one line
> conditionals" less explicitly clear than the multi-line equivalent.
Pascal doesn't care how many lines you use to achieve the desired style.
But for your case above, the unnecessary "else" and other blank fodder
really doesn't add to readabilty, IMO. Of course in C everything helps.
I personally like single lines for non-else'd cases with a simple
(single) action as above. Otherwise
if bar(foo) then
begin
brat (tat);
stat (a,v)
end
else
faggetaboutit("I object!");
But you can establish any style you're comfortable with.
>>> What? Never heard of
>>> #define BEGIN {
>>> #define END }
>>> ?
>>> :)
>>
>> Lipstick on a pig?
>
> No, a simple way to get the "BEGIN" and "END" that some prefer.
I did figure that out.
--
... it may be that "in the cloud" really isn't the best term
for the services these companies offer. What they really
want is to have us "on the leash."
-David Pogue, Scientific American, 2014.02
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-02-24 04:21 +0000 |
| Message-ID | <slrnlgli63.fcb.g.kreme@amelia.local> |
| In reply to | #56928 |
In message <ItGdnd5-bfmfB5fOnZ2dnUVZ_qmdnZ2d@giganews.com>
Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> if bar(foo) then
> begin
> brat (tat);
> stat (a,v)
> end
> else
> faggetaboutit("I object!");
Is how I would space that. However, that else is something I
particularly dislike. That, to me, is terrible obtuse code.
if bar(foo) {
brat(tat);
stat(a,v);
} else {
faggetaboutit("I object!");
}
That is much clearer and more concise that the code above.
I don't like putting {'s on empty lines for no reason, but the last
close bracket matches up the else and if showing the block has ended.
That said, I can't stand writing in python because of its reliance of
using white space for block control. That seems like the stupidest idea
any language designer ever had.
--
Technically, Aziraphale was a Principality, but people made jokes about
that these days
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web