* OpenSSL development (Heartbleed) @ 2014-04-19 14:31 Alan Browne 2014-04-19 15:06 ` Nasser M. Abbasi ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 14:31 UTC (permalink / raw) Good article in the NYT: http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 14:31 OpenSSL development (Heartbleed) Alan Browne @ 2014-04-19 15:06 ` Nasser M. Abbasi 2014-04-19 15:41 ` Alan Browne 2014-04-19 15:36 ` Georg Bauhaus 2014-04-19 15:47 ` Yannick Duchêne (Hibou57) 2 siblings, 1 reply; 44+ messages in thread From: Nasser M. Abbasi @ 2014-04-19 15:06 UTC (permalink / raw) On 4/19/2014 9:31 AM, Alan Browne wrote: > > Good article in the NYT: > > http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business > Ok, I read the article. The main point seems to blame lack of funding from corporation that use OpenSSL which is developed as open source by volunteers. Some student submitted a patch on eve of 2011 with the bug. The patch was "vetted" by a more senior developer later on, And so now we have it. I do not see anywhere, how is regression testing is done in this picture. Is there is lab full of networks and computers used to run thousands of regression tests each time a new software update is made? What was the result of these regression tests at that time? Where is the report on that? The problem seems to be with lack of test coverage and weak testing methodology used. May be due to lack of resourcesm or for other reasons. Yes, big companies need to donate more money to openSSL, but also testing should be improved. Other than the problem with using C, more internal testing is needed by open source developers. (Even more, since they use C, and not Ada :). --Nasser ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 15:06 ` Nasser M. Abbasi @ 2014-04-19 15:41 ` Alan Browne 0 siblings, 0 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 15:41 UTC (permalink / raw) On 2014.04.19, 11:06 , Nasser M. Abbasi wrote: > On 4/19/2014 9:31 AM, Alan Browne wrote: >> >> Good article in the NYT: >> >> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business >> >> > > Ok, I read the article. The main point seems to > blame lack of funding from corporation that use > OpenSSL which is developed as open source by > volunteers. > > Some student submitted a patch on eve of 2011 > with the bug. The patch was "vetted" by a more > senior developer later on, And so now we have it. > > I do not see anywhere, how is regression testing is > done in this picture. Is there is lab full of networks > and computers used to run thousands of regression > tests each time a new software update is made? What Testing? Bwahahahaahahahahahahahaahahahaaaaaaaaaa aaaa aaaa a a > was the result of these regression tests at that time? > Where is the report on that? The problem seems to > be with lack of test coverage and weak testing > methodology used. May be due to lack of resourcesm > or for other reasons. Resources - or rather how they are employed - is the primary issue. > > Yes, big companies need to donate more money to > openSSL, but also testing should be improved. > > Other than the problem with using C, more internal > testing is needed by open source developers. (Even more, > since they use C, and not Ada :). Language is not the issue. The issue is a lack of defined requirements which leads to design, documentation, testing, etc. For something as critical as SSL one would hope that more care would go into change management and testing. But that's a laugh in open source - everyone wants to code - not document. Someone receiving $2K a year (if that) is not going to spend much time editing and revising requirements... and students working on it see their code "working" and that is sufficient. Time to move on to getting your paws up Susie's skirt or finding a job at McDonald's. Apple went a different direction. Not especially for security reasons but that they found OpenSSL bloated and no longer fitting their future needs. http://appleinsider.com/articles/14/04/18/how-apple-dodged-the-heartbleed-bullet But they still do everything in C variants and that is not going to change. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 14:31 OpenSSL development (Heartbleed) Alan Browne 2014-04-19 15:06 ` Nasser M. Abbasi @ 2014-04-19 15:36 ` Georg Bauhaus 2014-04-19 16:00 ` Yannick Duchêne (Hibou57) 2014-04-19 16:06 ` Alan Browne 2014-04-19 15:47 ` Yannick Duchêne (Hibou57) 2 siblings, 2 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 15:36 UTC (permalink / raw) On 19/04/14 16:31, Alan Browne wrote: > > Good article in the NYT: > > http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business > An exquisite example of how journalism keeps contributing to tactically keeping everyone uninformed, for money (ads, or subscription). But, well, it ends in fundraising, for whatever allegedly good thing having somehow to do with OpenSSL. Scene: We've got an accident! (A big bug in who-knows-what causing ...). Starring: software people, politicians, companies, passwords, funding. Unquestioned semitheories, by emphasis: - Open Source means unpaid, voluntary weekend work. - Open Source means eyeballs looking at others' software, hence quality assurance. So vastly unspecific, incomplete, and untestable as stated, this is a good start for putting opinions on just something in contrast; the conditional of the second hypothesis is in and of itself good for rhetoric. The author indicates that there is no clear indication of the actual harm done (while at about the same time some lad finds himself arrested for doing harm (sniffing social security numbers) using the Heartbleed bug). Quoted "expert" (E. S. Raymond) says: there weren't any eyeballs watching the software. (Misquote? After all, the author names the reviewing software person.) But the expert is popular and controversial, so he's a perfect journalistic asset (triggers Raymond gossip and Raymond controversy). Finally, the author announces a fundraising project of said expert. Good advertising. In between, reports of booing, bemoaning, and demanding; journalist tries to establish a scape goat (OpenSSL users don't fund!). No proof, no clear indication of causation, but alluding in style. By saying that OpenSSL is not a well funded project, she obviously tries to imply that this is (a) true in effect, and (b) that funding prevents bugs. (a): most of OpenSSL does exist only after work of payed employees. (b): See bugs discovered at the same time in well funded MS Word and MS Outlook projects, of similar reach. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 15:36 ` Georg Bauhaus @ 2014-04-19 16:00 ` Yannick Duchêne (Hibou57) 2014-04-19 16:34 ` Georg Bauhaus 2014-04-19 16:06 ` Alan Browne 1 sibling, 1 reply; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-19 16:00 UTC (permalink / raw) Le Sat, 19 Apr 2014 17:36:17 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit: > > In between, reports of booing, bemoaning, and demanding; journalist > tries to establish a scape goat (OpenSSL users don't fund!). > No proof, no clear indication of causation, but alluding in style. > By saying that OpenSSL is not a well funded project, she obviously > tries to imply that this is (a) true in effect, That's a well established fact in the software area, so the assumption is honest enough. > and (b) that funding > prevents bugs.(a): most of OpenSSL does exist only after work > of payed employees. (b): See bugs discovered at the same time in well > funded MS Word and MS Outlook projects, of similar reach. Obviously, funding does not make miracles but neither free as in free‑beer do. However you are more likely to get people sticking to good methods, give time and energy for this, if they get something in return. Funding does not make people do a good job automatically, but it still make it more likely to be than with the opposite. -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:00 ` Yannick Duchêne (Hibou57) @ 2014-04-19 16:34 ` Georg Bauhaus 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 16:34 UTC (permalink / raw) On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote: > Le Sat, 19 Apr 2014 17:36:17 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit: >> >> In between, reports of booing, bemoaning, and demanding; journalist >> tries to establish a scape goat (OpenSSL users don't fund!). >> No proof, no clear indication of causation, but alluding in style. >> By saying that OpenSSL is not a well funded project, she obviously >> tries to imply that this is (a) true in effect, > > That's a well established fact in the software area, so the assumption is honest enough. That Funding = Quality_Assurance is a repeatedly established belief in talking about the "software area", so the only thing one can honestly assume is that people are going to repeat it. All of: the discovery of a bug, the review process, if any, are empirically observable facts, to some extent, though not always publicly observable. The results will depend on the instruments of observation. The interpretation of results can be subject to review etc. (Rarely, if ever, do we get to see the "issues" that affect the most widespread OS of all, e.g.) Examples include the Heartbeat bug (OpenSSL), the GotoFail bug (Apple), the RTF bug, and several others on record at the CVE database, things known by prefixes "KB" and "HT", etc. >> and (b) that funding >> prevents bugs.(a): most of OpenSSL does exist only after work >> of payed employees. (b): See bugs discovered at the same time in well >> funded MS Word and MS Outlook projects, of similar reach. > > Obviously, funding does not make miracles but neither free as in free‑beer do. This says what doesn't produce miracles: both funding and not funding, hence everything. A rhetorically and politically usable statement, though pointless. It wasn't claimed that free or free-beer would would produce miracles! That claim would be journalistic implication. > However you are more likely to get people sticking to good methods, give time and energy for this, if they get something in return. Well, that again makes for a hypothesis that is so unspecific that it fits the same bill: correlation turned causal based on likelihood, ceteris paribus. E.g., what are the specifics in terms of work hours, pay, and project characteristics? Do we have control-group like evidence? Can you substantiate your claim a little? ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:34 ` Georg Bauhaus @ 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) 2014-04-19 19:13 ` Georg Bauhaus 2014-04-19 19:42 ` Alan Browne 2014-04-21 23:51 ` Randy Brukardt 2 siblings, 1 reply; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-19 17:06 UTC (permalink / raw) Le Sat, 19 Apr 2014 18:34:13 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit: >> That's a well established fact in the software area, so the assumption >> is honest enough. > > That Funding = Quality_Assurance is a repeatedly established > belief in talking about the "software area", so the only thing > one can honestly assume is that people are going to repeat it. Not a belief, a practical fact. It happens I discovered bugs in some misc open‑source software, but either did not solved/investigated it, because I have enough things to solve in my own life. If helping others in solving this would have make them help/support me in return, this would have been different. Another variant is when it happened I discovered bugs, investigated these, proposed a fix, and the fix was rejected for mysterious reasons and I did not insist because I did not have time to fight for this, for similar reasons as above. That's just real life. There is a well known philosophy in the Ada world, which cleverly says “programming is a human activity” with a strong emphasis on “human” and it's characteristics, which means, it's not something outside of human contingencies. -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) @ 2014-04-19 19:13 ` Georg Bauhaus 2014-04-19 20:39 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 19:13 UTC (permalink / raw) On 19/04/14 19:06, Yannick Duchêne (Hibou57) wrote: > Le Sat, 19 Apr 2014 18:34:13 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit: > >>> That's a well established fact in the software area, so the assumption is honest enough. >> >> That Funding = Quality_Assurance is a repeatedly established >> belief in talking about the "software area", so the only thing >> one can honestly assume is that people are going to repeat it. > > Not a belief, a practical fact. It happens I discovered bugs in some misc open‑source software, > but either did not solved/investigated it, because I have enough things to solve in my own life. > If helping others in solving this would have make them help/support me in return, this would have been different. So you were presuming that if you had done something, they would not have done something in return to help you? Your fact so far seems this: "In my real life I didn't do something, because I didn't expect returns." OK. Do we have reasons, not opinions, to generalize this description in ways that are demonstrably applicable to cases like Heartbleed? So that economic decisions can be based on facts? (If they ever are.) > Another variant is when it happened I discovered bugs, investigated these, proposed a fix, > and the fix was rejected for mysterious reasons and I did not insist because >I did not have time to fight for this, for similar reasons as above. What does funding or not of their project have to do with reasons forrejection? And what does funding or not of their project have to do with rejection or not? And what does funding or not of your project have to do with (reasons for) rejection? Apple, for example, is known to be secretive about how they will finally react, or not react, to bug reports. They are well funded. Thus it might be an ideal situation when funding means maintenance and (responsive) support, but I don't see that funding entails the latter two. > That's just real life. There is a well known philosophy in the Ada world, which cleverly says “programming is a human activity” with a strong emphasis on “human” and it's characteristics, which means, it's not something outside of human contingencies. Right, and rhetoric is a well established human activity, too. Human activities is what may or may not turn the hypothesis that Funding = Quality_Assurance into a fact, in each case. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 19:13 ` Georg Bauhaus @ 2014-04-19 20:39 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-19 20:39 UTC (permalink / raw) Le Sat, 19 Apr 2014 21:13:58 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit: > […] > > What does funding or not of their project have to do with > reasons forrejection? And what does funding or not of their > project have to do with rejection or not? And what does funding > or not of your project have to do with (reasons for) rejection? > > Apple, for example, is known to be secretive about how they will > finally react, or not react, to bug reports. They are well funded. > > Thus it might be an ideal situation when funding means maintenance > and (responsive) support, but I don't see that funding entails > the latter two. > > […] > > Right, and rhetoric is a well established human activity, too. > Human activities is what may or may not turn the hypothesis that > Funding = Quality_Assurance into a fact, in each case. You show it does not always help, especially with some companies. OK. Since the initial message, I have not suggested it's a mechanical rule, just that there are things which may help and others which may make it less likely (I suspect we may somewhat agree on this). Offering a favourable context, surely can help. If ever you doubt it can help, just think about these graduate schools dropping Ada courses because their students want to learn something which come with paid job (not unpaid volunteer job) opportunities, and this is so even in france, “the country of Ada” (just teasing with what's in quotes… I know many countries are country of Ada too). I will stop arguing on this, with this message, which will be the last one :-P . -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:34 ` Georg Bauhaus 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) @ 2014-04-19 19:42 ` Alan Browne 2014-04-21 23:51 ` Randy Brukardt 2 siblings, 0 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 19:42 UTC (permalink / raw) On 2014.04.19, 12:34 , Georg Bauhaus wrote: > That Funding = Quality_Assurance is a repeatedly established > belief in talking about the "software area", so the only thing > one can honestly assume is that people are going to repeat it. Look at avionics - where Ada is heavily used for DO-178B level A, B, C software. The required software quality process is a major expense, and it is the least inspiring/interesting part of the whole for everyone involved (except the SQA people). But it unquestionably leads to fewer bugs - esp. on changes to software. It does not lead to fast. So while Funding = Q_A may not be true as an absolute statement, real Q_A per requirements[1] requires funding - nobody will do it out of the goodness of their hearts or as a hobby or to polish the boss's apple. It's tedious stuff. [1] legal requirement. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:34 ` Georg Bauhaus 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) 2014-04-19 19:42 ` Alan Browne @ 2014-04-21 23:51 ` Randy Brukardt 2014-04-22 15:20 ` G.B. 2 siblings, 1 reply; 44+ messages in thread From: Randy Brukardt @ 2014-04-21 23:51 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 2823 bytes --] "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net... > On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote: ... >> However you are more likely to get people sticking to good methods, give >> time and energy for this, if they get something in return. > > Well, that again makes for a hypothesis that is so unspecific > that it fits the same bill: correlation turned causal based on > likelihood, ceteris paribus. > E.g., what are the specifics in terms of work hours, pay, and > project characteristics? Do we have control-group like evidence? I can give you a couple of data points: First, the state of Ada standardization when I was funded to do administrative tasks. Before I took over, the ARG had a succession of volunteer editors. Toward the end, the only thing produced was meeting minutes. No one had organized the suggested changes, or figured out the effect on the standard (in some cases, the suggested changes were impossible to fit into the standard and we ended up coming up with completely different resolutions). Once I took over, I spent a lot of time on that sort of administrative tasks, and in other things that improved the process, like having on-line access to version control for documents (prior to my taking over there was no version control and on-line access was only to the most recent posted version of a document - which often was well behind the current state). This work was (and is) not much fun, and I think only someone who was getting paid would do it for long. (I'll have been doing it 16 years this fall. Wow.) The second example is the ACATS. Here, I took over directly from another paid person (Dan Lehman at the AVO). So I needed to make few changes to the basic procedures or approaches; mainly I wrote down a lot of the procedures that hadn't been well-documented in the past, and added a few new ones to deal with public version control and a finer-grained and more formal approach to correcting tests and issuing new tests. In both cases, I think that having a paid person involved has ensured quality that otherwise would not have happened. Working with volunteers is often described as herding cats (because one can make little assumptions about deadlines or quality of work - even in a group as knowledgeable and committed as the ARG - one learns who can be trusted to do work on time, who will wait to the last minute, and who probably will never produce anything). Someone who can put the pieces together and is empowered to do that is critical - and that person has to have a way to eat on jobs that will take months. [Of course, my opinion here may be more than a little biased, so please draw your own conclusions.] Randy. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-21 23:51 ` Randy Brukardt @ 2014-04-22 15:20 ` G.B. 2014-04-22 16:33 ` Dmitry A. Kazakov 0 siblings, 1 reply; 44+ messages in thread From: G.B. @ 2014-04-22 15:20 UTC (permalink / raw) On 22.04.14 01:51, Randy Brukardt wrote: > "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message > news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net... >> On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote: > ... >>> However you are more likely to get people sticking to good methods, give >>> time and energy for this, if they get something in return. >> >> Well, that again makes for a hypothesis that is so unspecific >> that it fits the same bill: correlation turned causal based on >> likelihood, ceteris paribus. >> E.g., what are the specifics in terms of work hours, pay, and >> project characteristics? Do we have control-group like evidence? > > I can give you a couple of data points: > > First, the state of Ada standardization[...] Evidence, indeed! Now given ISO/IEC 27000, a family of standards revolving around security, and Heartbleed, what can anyone do to make standards effecive? The money paid for the standardization of security procedures seems not to have affected the source code of one commercial security "procedure", OpenSSL. If Heartbleed is characteristic of paid standardization's actual outcome, then something is wrong somewhere. Absurd, in fact. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-22 15:20 ` G.B. @ 2014-04-22 16:33 ` Dmitry A. Kazakov 2014-04-22 16:57 ` Simon Clubley 0 siblings, 1 reply; 44+ messages in thread From: Dmitry A. Kazakov @ 2014-04-22 16:33 UTC (permalink / raw) On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote: > On 22.04.14 01:51, Randy Brukardt wrote: >> "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message >> news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net... >>> On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote: >> ... >>>> However you are more likely to get people sticking to good methods, give >>>> time and energy for this, if they get something in return. >>> >>> Well, that again makes for a hypothesis that is so unspecific >>> that it fits the same bill: correlation turned causal based on >>> likelihood, ceteris paribus. >>> E.g., what are the specifics in terms of work hours, pay, and >>> project characteristics? Do we have control-group like evidence? >> >> I can give you a couple of data points: >> First, the state of Ada standardization[...] > > Evidence, indeed! > Now given ISO/IEC 27000, a family of standards revolving > around security, and Heartbleed, what can anyone do to make > standards effecive? Properly designed standards, maybe? Let me ask a stupid question. What has a transport level protocol to do with the application level's servers (and clients)? If it really were a strictly transport level, no implementation could leak data out of higher levels. Right? > The money paid for the standardization of > security procedures seems not to have affected the source code > of one commercial security "procedure", OpenSSL. > If Heartbleed is characteristic of paid standardization's > actual outcome, then something is wrong somewhere. You must have software market in first place. Anything which comes free has no value. There is no market pressure to improve quality and functionality because there is no liability either monetary or legal. Neither the model of "intellectual property" nor the free software model is working to reach these goals, in the sense of an optimization problem. > Absurd, in fact. Nothing absurd. If C is selected in the process over Ada, there is a reason for this. And this reason (which is not lack of {} braces, as people used to think) influences any SW developing as well. We see the fruits, more to come... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-22 16:33 ` Dmitry A. Kazakov @ 2014-04-22 16:57 ` Simon Clubley 2014-04-22 19:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 44+ messages in thread From: Simon Clubley @ 2014-04-22 16:57 UTC (permalink / raw) On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote: >> >> Evidence, indeed! >> Now given ISO/IEC 27000, a family of standards revolving >> around security, and Heartbleed, what can anyone do to make >> standards effecive? > > Properly designed standards, maybe? Let me ask a stupid question. What has > a transport level protocol to do with the application level's servers (and > clients)? If it really were a strictly transport level, no implementation > could leak data out of higher levels. Right? > No, properly _implemented_ standards are what is required. Heartbleed came about because a boundary check was missing which allowed a invalid request to be processed instead of being rejected and, because of the _implementation_, was allowed access to memory that had nothing to do with the request. This was a failure in the implementation of the standard, not a failure of the standard itself. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-22 16:57 ` Simon Clubley @ 2014-04-22 19:53 ` Dmitry A. Kazakov 2014-04-22 20:49 ` Yannick Duchêne (Hibou57) 2014-04-23 5:38 ` Natasha Kerensikova 0 siblings, 2 replies; 44+ messages in thread From: Dmitry A. Kazakov @ 2014-04-22 19:53 UTC (permalink / raw) On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote: > On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote: >>> >>> Evidence, indeed! >>> Now given ISO/IEC 27000, a family of standards revolving >>> around security, and Heartbleed, what can anyone do to make >>> standards effecive? >> >> Properly designed standards, maybe? Let me ask a stupid question. What has >> a transport level protocol to do with the application level's servers (and >> clients)? If it really were a strictly transport level, no implementation >> could leak data out of higher levels. Right? > > No, properly _implemented_ standards are what is required. > > Heartbleed came about because a boundary check was missing which allowed > a invalid request to be processed instead of being rejected and, because > of the _implementation_, was allowed access to memory that had nothing to > do with the request. > > This was a failure in the implementation of the standard, not a failure > of the standard itself. Boundary checks or not, the transport layer shall have no access to the server data. A tightly coupled system is vulnerable. If compromising just one component opens all gates wide, that is a bad standard and bad design. The effects of errors and faults must be bounded per design. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-22 19:53 ` Dmitry A. Kazakov @ 2014-04-22 20:49 ` Yannick Duchêne (Hibou57) 2014-04-23 5:38 ` Natasha Kerensikova 1 sibling, 0 replies; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-22 20:49 UTC (permalink / raw) Le Tue, 22 Apr 2014 21:53:01 +0200, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> a écrit: > Boundary checks or not, the transport layer shall have no access to the > server data. > > A tightly coupled system is vulnerable. If compromising just one > component > opens all gates wide, that is a bad standard and bad design. The effects > of > errors and faults must be bounded per design. There indeed can't be any “Correct By Construction” without this. -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-22 19:53 ` Dmitry A. Kazakov 2014-04-22 20:49 ` Yannick Duchêne (Hibou57) @ 2014-04-23 5:38 ` Natasha Kerensikova 2014-04-23 7:30 ` Dmitry A. Kazakov 1 sibling, 1 reply; 44+ messages in thread From: Natasha Kerensikova @ 2014-04-23 5:38 UTC (permalink / raw) On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote: >> No, properly _implemented_ standards are what is required. >> >> Heartbleed came about because a boundary check was missing which allowed >> a invalid request to be processed instead of being rejected and, because >> of the _implementation_, was allowed access to memory that had nothing to >> do with the request. >> >> This was a failure in the implementation of the standard, not a failure >> of the standard itself. > > Boundary checks or not, the transport layer shall have no access to the > server data. > > A tightly coupled system is vulnerable. If compromising just one component > opens all gates wide, that is a bad standard and bad design. The effects of > errors and faults must be bounded per design. How would you design a transport layer that has no access to whatever is supposed to be transported? "Heartbleed" didn't leak any data that ins't legitimataly needed by OpenSSL (i.e. transported data and/or transport parameters (like keys)) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 5:38 ` Natasha Kerensikova @ 2014-04-23 7:30 ` Dmitry A. Kazakov 2014-04-23 7:40 ` Natasha Kerensikova ` (2 more replies) 0 siblings, 3 replies; 44+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 7:30 UTC (permalink / raw) On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote: > On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote: >>> No, properly _implemented_ standards are what is required. >>> >>> Heartbleed came about because a boundary check was missing which allowed >>> a invalid request to be processed instead of being rejected and, because >>> of the _implementation_, was allowed access to memory that had nothing to >>> do with the request. >>> >>> This was a failure in the implementation of the standard, not a failure >>> of the standard itself. >> >> Boundary checks or not, the transport layer shall have no access to the >> server data. >> >> A tightly coupled system is vulnerable. If compromising just one component >> opens all gates wide, that is a bad standard and bad design. The effects of >> errors and faults must be bounded per design. > > How would you design a transport layer that has no access to whatever is > supposed to be transported? > > "Heartbleed" didn't leak any data that ins't legitimataly needed by > OpenSSL (i.e. transported data and/or transport parameters (like keys)) I heard it leaked user data, I didn't go into details. I hope user data are not transported, because otherwise that would be even an greater design fault. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 7:30 ` Dmitry A. Kazakov @ 2014-04-23 7:40 ` Natasha Kerensikova 2014-04-23 8:04 ` Dmitry A. Kazakov 2014-04-23 7:42 ` Egil H H 2014-04-23 8:06 ` Georg Bauhaus 2 siblings, 1 reply; 44+ messages in thread From: Natasha Kerensikova @ 2014-04-23 7:40 UTC (permalink / raw) On 2014-04-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: > On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote: > >> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >>> Boundary checks or not, the transport layer shall have no access to the >>> server data. >>> >>> A tightly coupled system is vulnerable. If compromising just one component >>> opens all gates wide, that is a bad standard and bad design. The effects of >>> errors and faults must be bounded per design. >> >> How would you design a transport layer that has no access to whatever is >> supposed to be transported? >> >> "Heartbleed" didn't leak any data that ins't legitimataly needed by >> OpenSSL (i.e. transported data and/or transport parameters (like keys)) > > I heard it leaked user data, I didn't go into details. I hope user data are > not transported, because otherwise that would be even an greater design > fault. Actually it leaked session cookies, that are legitimately part of any HTTP payload, and login/passwords, that are legitimately part of the HTTP payload of the authentication request. At that point the remaining of the user data is considered compromised as well, because of the possibility of session/credential hijacking, but that's only an indirect result of heartbleed, and requires a separate attack. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 7:40 ` Natasha Kerensikova @ 2014-04-23 8:04 ` Dmitry A. Kazakov 2014-04-23 8:20 ` Georg Bauhaus 0 siblings, 1 reply; 44+ messages in thread From: Dmitry A. Kazakov @ 2014-04-23 8:04 UTC (permalink / raw) On Wed, 23 Apr 2014 07:40:44 +0000 (UTC), Natasha Kerensikova wrote: > On 2014-04-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >> On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote: >> >>> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote: >>>> Boundary checks or not, the transport layer shall have no access to the >>>> server data. >>>> >>>> A tightly coupled system is vulnerable. If compromising just one component >>>> opens all gates wide, that is a bad standard and bad design. The effects of >>>> errors and faults must be bounded per design. >>> >>> How would you design a transport layer that has no access to whatever is >>> supposed to be transported? >>> >>> "Heartbleed" didn't leak any data that ins't legitimataly needed by >>> OpenSSL (i.e. transported data and/or transport parameters (like keys)) >> >> I heard it leaked user data, I didn't go into details. I hope user data are >> not transported, because otherwise that would be even an greater design >> fault. > > Actually it leaked session cookies, that are legitimately part of any > HTTP payload, and login/passwords, that are legitimately part of the > HTTP payload of the authentication request. > > At that point the remaining of the user data is considered compromised > as well, because of the possibility of session/credential hijacking, > but that's only an indirect result of heartbleed, and requires a > separate attack. To my limited knowledge it sent some dumps of the server's memory. Again, a silly Boy Scout's question, how a *transport* layer could even come to this? To me this looks a protocol layer encapsulation fault. (Not a big wonder considering the huge mess web protocols represent.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 8:04 ` Dmitry A. Kazakov @ 2014-04-23 8:20 ` Georg Bauhaus 0 siblings, 0 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-23 8:20 UTC (permalink / raw) On 23/04/14 10:04, Dmitry A. Kazakov wrote: > To my limited knowledge it sent some dumps of the server's memory. Again, a > silly Boy Scout's question, how a*transport* layer could even come to > this? > > To me this looks a protocol layer encapsulation fault. (Not a big wonder > considering the huge mess web protocols represent.) Some have found it suspicious that a "ping" like thing would transport anything, making this appear to be a backdoor. See fefe's blog, for example (German, Apr 9). "(...). Aus meiner Sicht riecht das wie eine Backdoor, es schmeckt wie eine Backdoor, es hat die Konsistenz einer Backdoor, und es sieht aus wie eine Backdoor". "(...). From my point of view it smells like a backdoor, it tastes like a backdoor, it has the texture of a backdoor, and it looks like a backdoor". This comment has been address by the OpenSSL author, a little later (ibd.). ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 7:30 ` Dmitry A. Kazakov 2014-04-23 7:40 ` Natasha Kerensikova @ 2014-04-23 7:42 ` Egil H H 2014-04-23 8:06 ` Georg Bauhaus 2 siblings, 0 replies; 44+ messages in thread From: Egil H H @ 2014-04-23 7:42 UTC (permalink / raw) On Wednesday, April 23, 2014 9:30:08 AM UTC+2, Dmitry A. Kazakov wrote: > > I heard it leaked user data, I didn't go into details. I hope user data are > > not transported, because otherwise that would be even an greater design > > fault. Here's a fairly good explanation: http://xkcd.com/1354/ ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-23 7:30 ` Dmitry A. Kazakov 2014-04-23 7:40 ` Natasha Kerensikova 2014-04-23 7:42 ` Egil H H @ 2014-04-23 8:06 ` Georg Bauhaus 2 siblings, 0 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-23 8:06 UTC (permalink / raw) On 23/04/14 09:30, Dmitry A. Kazakov wrote: >>> Boundary checks or not, the transport layer shall have no access to the >>> server data. >>> >>> A tightly coupled system is vulnerable. If compromising just one component >>> opens all gates wide, that is a bad standard and bad design. The effects of >>> errors and faults must be bounded per design. >> >> How would you design a transport layer that has no access to whatever is >> supposed to be transported? >> >> "Heartbleed" didn't leak any data that ins't legitimataly needed by >> OpenSSL (i.e. transported data and/or transport parameters (like keys)) > > I heard it leaked user data, I didn't go into details. I hope user data are > not transported, because otherwise that would be even an greater design > fault. They are not, by design, transported. I think the issue boiled down to using some int variable `p' as an offset without checking bounds. OpenSSL sometimes uses its own malloc, for historical reasons. So, perhaps this approximates. At least GNAT warns, no matter what. What do other compiler diagnose? with System.Storage_Elements; use System.Storage_Elements; with Ada.Integer_Text_IO; procedure Leak is type A is array (Integer range <>) of Storage_Element; type A_P is access all A; Pool : A (1 .. 123_456); for Pool'Address use To_Address (16#100_000#); Current_Offset : Storage_Offset := 0; function Our_Own_Malloc (Size : Natural) return A_P is Result : A_P; for Result'Address use Pool'Address + Current_Offset; begin Current_Offset := Current_Offset + Storage_Offset (Size); return Result; end Our_Own_Malloc; function Something (P : Integer) return A is Result : A_P; begin Result := Our_Own_Malloc (P); return Result.all; end Something; use Ada.Integer_Text_IO; I : Integer; begin Get(I); declare Y : A := Something (I); begin null; end; end Leak; ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 15:36 ` Georg Bauhaus 2014-04-19 16:00 ` Yannick Duchêne (Hibou57) @ 2014-04-19 16:06 ` Alan Browne 2014-04-19 16:42 ` Georg Bauhaus 1 sibling, 1 reply; 44+ messages in thread From: Alan Browne @ 2014-04-19 16:06 UTC (permalink / raw) On 2014.04.19, 11:36 , Georg Bauhaus wrote: > In between, reports of booing, bemoaning, and demanding; journalist > tries to establish a scape goat (OpenSSL users don't fund!). > No proof, no clear indication of causation, but alluding in style. > By saying that OpenSSL is not a well funded project, she obviously > tries to imply that this is (a) true in effect, and (b) that funding > prevents bugs. (a): most of OpenSSL does exist only after work > of payed employees. (b): See bugs discovered at the same time in well > funded MS Word and MS Outlook projects, of similar reach. And how does that make you feel? Please see this as well: http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage®ion=Marginalia&pgtype=article -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:06 ` Alan Browne @ 2014-04-19 16:42 ` Georg Bauhaus 2014-04-19 16:59 ` Georg Bauhaus 2014-04-19 19:12 ` Alan Browne 0 siblings, 2 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 16:42 UTC (permalink / raw) On 19/04/14 18:06, Alan Browne wrote: > On 2014.04.19, 11:36 , Georg Bauhaus wrote: > >> In between, reports of booing, bemoaning, and demanding; journalist >> tries to establish a scape goat (OpenSSL users don't fund!). >> No proof, no clear indication of causation, but alluding in style. >> By saying that OpenSSL is not a well funded project, she obviously >> tries to imply that this is (a) true in effect, and (b) that funding >> prevents bugs. (a): most of OpenSSL does exist only after work >> of payed employees. (b): See bugs discovered at the same time in well >> funded MS Word and MS Outlook projects, of similar reach. > > And how does that make you feel? Depends. Sometimes I feel that industry should rid itself of its dependence on so few suppliers of an ever increasing number of "industry standards", open source or not, and on PR style people. Some things are just too important for healthy living, both at work and at home. So important that these things should be exempt from being nothing but a business opportunity. > Please see this as well: > > http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage®ion=Marginalia&pgtype=article Same thing... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:42 ` Georg Bauhaus @ 2014-04-19 16:59 ` Georg Bauhaus 2014-04-19 19:12 ` Alan Browne 1 sibling, 0 replies; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 16:59 UTC (permalink / raw) On 19/04/14 18:42, Georg Bauhaus wrote: > exempt from being nothing but a business opportunity. Sorry, "barred", "excluded", or "saved" probably are better words. I don't have software to help me with English... ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:42 ` Georg Bauhaus 2014-04-19 16:59 ` Georg Bauhaus @ 2014-04-19 19:12 ` Alan Browne 2014-04-19 20:20 ` Georg Bauhaus 1 sibling, 1 reply; 44+ messages in thread From: Alan Browne @ 2014-04-19 19:12 UTC (permalink / raw) On 2014.04.19, 12:42 , Georg Bauhaus wrote: > On 19/04/14 18:06, Alan Browne wrote: >> On 2014.04.19, 11:36 , Georg Bauhaus wrote: >> >>> In between, reports of booing, bemoaning, and demanding; journalist >>> tries to establish a scape goat (OpenSSL users don't fund!). >>> No proof, no clear indication of causation, but alluding in style. >>> By saying that OpenSSL is not a well funded project, she obviously >>> tries to imply that this is (a) true in effect, and (b) that funding >>> prevents bugs. (a): most of OpenSSL does exist only after work >>> of payed employees. (b): See bugs discovered at the same time in well >>> funded MS Word and MS Outlook projects, of similar reach. >> >> And how does that make you feel? > > Depends. Sometimes I feel that industry should rid itself of > its dependence on so few suppliers of an ever increasing number > of "industry standards", open source or not, and on > PR style people. Some things are just too important for healthy > living, both at work and at home. So important that these things > should be exempt from being nothing but a business opportunity. I think so too. IMO interchange on intra/internets should be formal standards based. Those standards should be done in the same manner as aerospace and defense s/w. It's okay if a pool of companies create the company that does so - but the sole source of release should be that company. >> Please see this as well: >> >> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage®ion=Marginalia&pgtype=article >> > > Same thing... No. Where OpenSSL is underfunded and has a population of maybe 4 programmers dedicated to it (the guy who created the bug not being one of the 4) released an important security breach upon the masses; Contrast with OpenSourced Linux which has a well (corporate) funded organization and has a lot more eyeballs on the code and hasn't (Linux itself) suffered any major or embarrassing problems. That was the point of the article. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 19:12 ` Alan Browne @ 2014-04-19 20:20 ` Georg Bauhaus 2014-04-19 20:53 ` Alan Browne 0 siblings, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 20:20 UTC (permalink / raw) On 19/04/14 21:12, Alan Browne wrote: > > No. Where OpenSSL is underfunded and has a population of maybe 4 programmers dedicated to it (the guy who created the bug not being one of the 4) released an important security breach upon the masses; > > Contrast with OpenSourced Linux which has a well (corporate) funded organization and has a lot more eyeballs on the code and hasn't (Linux itself) suffered any major or embarrassing problems. A comparison of one bug in one library to bugs in the amount of software that is "Enterprise Linux" does not seem balanced enough. Also, insofar as OpenSSL is well associated with open source Linux, it is likely that fixing Heartbleed-like bugs will be covered by {Redhat, ...} support. This adds to an argument that there actually is funding for OpenSSL etc., or, conversely, that there is never enough funding for all the software to be bug free. At least, that seems to be the argument of the articles: that funding and enterprise support is supposed to achieve so high a quality of software that it would have prevented Heartbleed etc. OTOH, and bringing this back to Ada, the CVE sites state quite openly that most of the issues have to do with int, malloc, computed pointers, and assumptions that are not reflected in all of these (overflow, say). If it is possible to make programmers use an Ada style fundamental type system instead, thus also better arrays and fewer pointers, this change would naturally reflect more of the assumptions. The conclusion can only be that this change makes the software so written as good as the assumptions. According to McCormick's findings, that's not nothing. The fundamentals do matter. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 20:20 ` Georg Bauhaus @ 2014-04-19 20:53 ` Alan Browne 2014-04-19 21:10 ` [OT] OpenBSD, was: " Simon Clubley 2014-04-20 8:17 ` Georg Bauhaus 0 siblings, 2 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 20:53 UTC (permalink / raw) On 2014.04.19, 16:20 , Georg Bauhaus wrote: > On 19/04/14 21:12, Alan Browne wrote: >> >> No. Where OpenSSL is underfunded and has a population of maybe 4 >> programmers dedicated to it (the guy who created the bug not being one >> of the 4) released an important security breach upon the masses; >> >> Contrast with OpenSourced Linux which has a well (corporate) funded >> organization and has a lot more eyeballs on the code and hasn't (Linux >> itself) suffered any major or embarrassing problems. > > A comparison of one bug in one library to bugs in the amount of > software that is "Enterprise Linux" does not seem balanced > enough. I was simply refuting that the 2nd article was the "same thing" as the first. The 2nd pointed out two cases. > Also, insofar as OpenSSL is well associated with > open source Linux, it is likely that fixing Heartbleed-like > bugs will be covered by {Redhat, ...} support. This adds to > an argument that there actually is funding for OpenSSL etc., > or, conversely, that there is never enough funding for all the > software to be bug free. OpenSSL appears from these reports to be "out on the limb" away from the more richly supported trunk. > At least, that seems to be the argument of the articles: > that funding and enterprise support is supposed to achieve > so high a quality of software that it would have prevented > Heartbleed etc. Reduced the likelihood, anyway. Truly, it would be better if requirements were set and then the s/w designed, nay, engineered, to meet the requirements. One day perhaps. But until someone (an entity) seizes control of the release process, there will be no engineering to a level that would prevent these sorts of problems. This is not the last. > OTOH, and bringing this back to Ada, the CVE sites state quite > openly that most of the issues have to do with int, malloc, > computed pointers, and assumptions that are not reflected in all > of these (overflow, say). QUOTE Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects, has criticized the OpenSSL developers for writing their own memory management routines and thereby circumventing OpenBSD C standard library exploit countermeasures, saying "OpenSSL is not developed by a responsible team." ENDQUOTE Ironic that one Open team leader is criticizing another <g> But, he may be right. Would he subject his teams to a more rigorous process? To Ada? > If it is possible to make programmers use an Ada style fundamental > type system instead, thus also better arrays and fewer pointers, > this change would naturally reflect more of the assumptions. The > conclusion can only be that this change makes the software so written > as good as the assumptions. According to McCormick's findings, > that's not nothing. The fundamentals do matter. Of course they do. Now, do you really think the industry will change to something more formalized and requirements driven? Use Ada as a fundamental building block of it? -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed) 2014-04-19 20:53 ` Alan Browne @ 2014-04-19 21:10 ` Simon Clubley 2014-04-19 21:53 ` Alan Browne 2014-04-20 8:17 ` Georg Bauhaus 1 sibling, 1 reply; 44+ messages in thread From: Simon Clubley @ 2014-04-19 21:10 UTC (permalink / raw) On 2014-04-19, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.04.19, 16:20 , Georg Bauhaus wrote: >> OTOH, and bringing this back to Ada, the CVE sites state quite >> openly that most of the issues have to do with int, malloc, >> computed pointers, and assumptions that are not reflected in all >> of these (overflow, say). > > QUOTE > Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects, > has criticized the OpenSSL developers for writing their own memory > management routines and thereby circumventing OpenBSD C standard library > exploit countermeasures, saying "OpenSSL is not developed by a > responsible team." > ENDQUOTE > > Ironic that one Open team leader is criticizing another <g> > Not if you know what Theo is like. :-) > But, he may be right. > > Would he subject his teams to a more rigorous process? To Ada? > Yes to the first; unknown on the second. OpenBSD has a reputation as a reasonably secure (by Unix standards) operating system precisely due to the auditing the OpenBSD team carries out. Note that this is a reputation based assessment; I don't have much direct experience with OpenBSD. Some reading you may find of interest: http://www.openbsd.org/security.html Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed) 2014-04-19 21:10 ` [OT] OpenBSD, was: " Simon Clubley @ 2014-04-19 21:53 ` Alan Browne 2014-04-19 22:15 ` Nasser M. Abbasi 0 siblings, 1 reply; 44+ messages in thread From: Alan Browne @ 2014-04-19 21:53 UTC (permalink / raw) On 2014.04.19, 17:10 , Simon Clubley wrote: > On 2014-04-19, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >> On 2014.04.19, 16:20 , Georg Bauhaus wrote: >>> OTOH, and bringing this back to Ada, the CVE sites state quite >>> openly that most of the issues have to do with int, malloc, >>> computed pointers, and assumptions that are not reflected in all >>> of these (overflow, say). >> >> QUOTE >> Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects, >> has criticized the OpenSSL developers for writing their own memory >> management routines and thereby circumventing OpenBSD C standard library >> exploit countermeasures, saying "OpenSSL is not developed by a >> responsible team." >> ENDQUOTE >> >> Ironic that one Open team leader is criticizing another <g> >> > > Not if you know what Theo is like. :-) > >> But, he may be right. >> >> Would he subject his teams to a more rigorous process? To Ada? >> > > Yes to the first; unknown on the second. > > OpenBSD has a reputation as a reasonably secure (by Unix standards) > operating system precisely due to the auditing the OpenBSD team > carries out. > > Note that this is a reputation based assessment; I don't have much > direct experience with OpenBSD. > > Some reading you may find of interest: > > http://www.openbsd.org/security.html Seen it before. I don't really believe their philosophy is forward thinking. (Audit things to death and you will find bugs and improve the system) is not what the world should be doing. It should be designing and engineering things so that they are not likely to have security holes and bugs in the first place. In effect they are confirming that C is a terrible language to write anything requiring security and so it needs never ending vigilance. So what they are doing is right for anything written in Cieve. (Get it? C + Sieve = Cieve). Not to say Ada results in bullet proof - but if used as intended there would be very few security holes of the many sorts that seem to pop up. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed) 2014-04-19 21:53 ` Alan Browne @ 2014-04-19 22:15 ` Nasser M. Abbasi 2014-04-19 22:34 ` Alan Browne 0 siblings, 1 reply; 44+ messages in thread From: Nasser M. Abbasi @ 2014-04-19 22:15 UTC (permalink / raw) On 4/19/2014 4:53 PM, Alan Browne wrote: > > In effect they are confirming that C is a terrible language to write > anything requiring security and so it needs never ending vigilance. > Sure. When the language is weakly typed, more manual effort in terms of more code eye balling, more debugging, more testing and more code inspection is needed relative to using a strongly typed language. Instead of getting help from the language/compiler in finding many errors early on, human time and effort is used instead to compensate. This is nothing new ;) > Not to say Ada results in bullet proof - but if used as intended there > would be very few security holes of the many sorts that seem to pop up. > --Nasser ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed) 2014-04-19 22:15 ` Nasser M. Abbasi @ 2014-04-19 22:34 ` Alan Browne 0 siblings, 0 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 22:34 UTC (permalink / raw) On 2014.04.19, 18:15 , Nasser M. Abbasi wrote: > On 4/19/2014 4:53 PM, Alan Browne wrote: > >> >> In effect they are confirming that C is a terrible language to write >> anything requiring security and so it needs never ending vigilance. >> > > Sure. When the language is weakly typed, more manual > effort in terms of more code eye balling, more debugging, > more testing and more code inspection is needed relative > to using a strongly typed language. Instead of getting > help from the language/compiler in finding many errors > early on, human time and effort is used instead to > compensate. > > This is nothing new ;) I know - this was all reflection on the Pot (Mr. OpenBSD) calling the kettle (the OpenSSL four) black. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 20:53 ` Alan Browne 2014-04-19 21:10 ` [OT] OpenBSD, was: " Simon Clubley @ 2014-04-20 8:17 ` Georg Bauhaus 2014-04-20 16:49 ` Alan Browne 1 sibling, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2014-04-20 8:17 UTC (permalink / raw) On 19/04/14 22:53, Alan Browne wrote: > Now, do you really think the industry will change to something more formalized and requirements driven? Use Ada as a fundamental building block of it? Where C (or no S/E) is being used, directly, or indirectly by using libraries written in C, the industry seems stuck in a loop of at least (1) self-referential confirmation, (2) insufficient irritation caused by C (or lack of S/E), and (3) sufficient competitive equality. One faint hope that I currently maintain is that some BigCo, not the industry, might produce a change to using C. The change might be like the ones just now performed in the case of hugely popular languages: PHP might become Hack everywhere because Facebook has produced Hack by "enhancing" PHP; Microsoft has already produced C#, VB#, etc., by "enhancing" each of the respective assimilated languages; Apple's "enhanced" C in Objective-C is already far above what the C standard requires of an implementation if seen through the lenses of their static analyzer. Google makes their talented staff spend some "free" time on "enhancing" the special qualities of JavaScript. And the results are all free, working, and ubiquitous. Suppose something similar happens in the C world. Apparently, all it takes is hiring a few smart compiler writers and have them "enhance" the popular language C in such a way that C programmers can simply enjoy the new features whenever they wish. (Intel?, Freescale?) To elaborate, for the sake of completeness only, the claims of (1), (2), and (3), (1) As long as the company does not go bankrupt, and the project's goal was not entirely missed, choosing C is justified. So, project management can confirm that it was the right choice, obviously. So does everyone. (2) It is well known that: "Software has bugs." "Tom De Marco says that the effect of language is <= 5%, so why bother." Studies comparing the effects of languages or methods are rare. They seem to be interpreted by shooting from the hip or in other surprising ways[*]. If effects of bugs can be handled by customer care, then C's features may be seen as causing costly bugs, however the pressure isn't high enough. Internally, excuses are at hand. (Not the least of which is "A..... 5!") (3) By simple arithmetic, if all the competition is using C (or no S/E), everyone incurs the same cost, yet there is return on investment. Consequently, then, using C (or no S/E) does not cause any relative economic disadvantage. Whereas investing in different technology is associated with risk, education, and other cost factors. Who is going to start an initiative, then, and why? __ [*] One anecdote I heard was about two teams, one using C++, the other using SPARK, programming to the same specification for one year. Either team could use a simulator. The teams were tasked with producing programs for driving a test device. The C++ team debugged their software into existence, frequently testing in the simulator. The SPARK team first found a bug in the specification, then went on to prove software into existence, hardly if ever using the simulator. Finally, the C++ team had implemented 80% of the features. Some bugs were found in the final product. The SPARK team had implemented 100% of the features (close to closing time). No bugs were found in the final product. Interpretation of the result: Use of the approach of C++ is preferable since project management then does not suffer a heart attack because they have no facts to report while the project is underway. ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-20 8:17 ` Georg Bauhaus @ 2014-04-20 16:49 ` Alan Browne 2014-04-22 12:18 ` G.B. 0 siblings, 1 reply; 44+ messages in thread From: Alan Browne @ 2014-04-20 16:49 UTC (permalink / raw) On 2014.04.20, 04:17 , Georg Bauhaus wrote: > On 19/04/14 22:53, Alan Browne wrote: >> Now, do you really think the industry will change to something more >> formalized and requirements driven? Use Ada as a fundamental building >> block of it? > > Where C (or no S/E) is being used, directly, or indirectly by using > libraries written in C, the industry seems stuck in a loop of at least > > (1) self-referential confirmation, > (2) insufficient irritation caused by C (or lack of S/E), and > (3) sufficient competitive equality. > > One faint hope that I currently maintain is that some BigCo, not the > industry, might produce a change to using C. The change might be like > the ones just now performed in the case of hugely popular languages: > PHP might become Hack everywhere because Facebook has produced Hack by > "enhancing" PHP; Microsoft has already produced C#, VB#, etc., by > "enhancing" each of the respective assimilated languages; Apple's > "enhanced" C in Objective-C is already far above what the C standard > requires of an implementation if seen through the lenses of their > static analyzer. Google makes their talented staff spend some "free" > time on "enhancing" the special qualities of JavaScript. > > And the results are all free, working, and ubiquitous. Is it possible to identify a particular client side layer item (app, transport, internet or link) that is relatively small that could be designed and written in Ada and that could "drop in" as a replacement? Obviously it would have to hook up and down in the system and 'look' for all intents and purposes like its C predecessor? That would be a good proving ground for an Ada approach. How to link them to the "C" code above and below .... __ > [*] One anecdote I heard was about two teams, one using C++, the > other using SPARK, programming to the same specification for one > year. Either team could use a simulator. The teams were tasked with > producing programs for driving a test device. The C++ team > debugged their software into existence, frequently testing in the > simulator. The SPARK team first found a bug in the specification, > then went on to prove software into existence, hardly if ever using > the simulator. Finally, the C++ team had implemented 80% of the features. > Some bugs were found in the final product. The SPARK team had > implemented 100% of the features (close to closing time). No bugs > were found in the final product. > Interpretation of the result: Use of the approach of C++ is > preferable since project management then does not suffer a heart > attack because they have no facts to report while the project > is underway. Amusing. But there's nothing to prevent progress reporting on non-spiral development - the gates just have to be defined correctly. Reminds me of a programmer assigned, alone, to write the software for an avionics system. He chose assembler on a microprocessor for which he had no experience. (We were not yet at the "ban assembler" point). He designed (eg: wrote the documentation to full draft). He followed the new programming style guidelines from our SQA. He coded (hand written - believe it or not). When his code was 100% written to spec, he and a word processing girl began entering the source code (she worked about 10x faster than him). Then, with 100% of the code entered, he began assembling the files. Then, through generated errors and in examining the machine code, he discovered that his understanding of the register set and memory model of the 8086 were completely wrong. So. He went back to his desk and began re-coding the entire thing in assembler again. Hand written. (But this time handed them off to the WP lady to enter the next day). The re-coding didn't take very long since the overall design did not change at all. (This is really the important part). He assembled. He corrected. He loaded the code onto the engineering prototype h/w and found a few bugs. From the first loadable executable to an on-spec bug free system took less than a working week (he worked 10 to 6. No more. No less. Ever). He didn't use the nice ICE system we had. And ahead of schedule. This rare discipline in programming I've never seen since. The funny thing was he was a mathematician and didn't like computers much - but had found a job as a programmer... -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-20 16:49 ` Alan Browne @ 2014-04-22 12:18 ` G.B. 0 siblings, 0 replies; 44+ messages in thread From: G.B. @ 2014-04-22 12:18 UTC (permalink / raw) On 20.04.14 18:49, Alan Browne wrote: > Is it possible to identify a particular client side layer item (app, > transport, internet or link) that is relatively small that could be > designed and written in Ada and that could "drop in" as a replacement? > > Obviously it would have to hook up and down in the system and 'look' for > all intents and purposes like its C predecessor? One such example is the Ironsides DNS server, I think, http://ironsides.martincarlisle.com/ I guess the program may well be a target for appraisal. In any case, since this can replace one layer item, it is proof of concept. Would people at Cisco take note of the possibilities of "language advantages", and S/E? (If they are "allowed" to make their devices more secure, which I do not know.) http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed Another hint is found in the use of Ada when cracking the Lorenz code. According to the winner, the cryptographic algorithms were expressed more clearly, and, quoting, *concisely*! http://www.drdobbs.com/parallel/tunny-colossus-and-ada-keeping-an-open/207800151 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 14:31 OpenSSL development (Heartbleed) Alan Browne 2014-04-19 15:06 ` Nasser M. Abbasi 2014-04-19 15:36 ` Georg Bauhaus @ 2014-04-19 15:47 ` Yannick Duchêne (Hibou57) 2014-04-19 16:21 ` Alan Browne 2 siblings, 1 reply; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-19 15:47 UTC (permalink / raw) Le Sat, 19 Apr 2014 16:31:39 +0200, Alan Browne <alan.browne@freelunchvideotron.ca> a écrit: > > Good article in the NYT: > > http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business > I surely gonna be blamed for saying this, however what can be noted here, is that a [political] movement which is always shouting at commercial companies is at the same time always expecting funds from them. How can you one be serious expecting the end of something while organizing a dependency on this thing? Also, and that's not a surprise, nothing is expected from “ordinary users”, who do benefit as much from unsupported/unpaid jobs as commercial companies do. People should stop believing in miracles and magic formulas and become responsible (all the people, not just the commercial companies as a well know political movement suggest). There is nothing one can get for strictly nothing (for a little fee may be practical, but not for strictly nothing), even with software (which is not just a matter of copying files as a well known movement wants to make people believe). I hope someone will be able to bring back basic economic principles in this area some day in the future. -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 15:47 ` Yannick Duchêne (Hibou57) @ 2014-04-19 16:21 ` Alan Browne 2014-04-19 16:46 ` Georg Bauhaus 2014-04-19 16:50 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 16:21 UTC (permalink / raw) On 2014.04.19, 11:47 , Yannick Duchêne (Hibou57) wrote: > Le Sat, 19 Apr 2014 16:31:39 +0200, Alan Browne > <alan.browne@freelunchvideotron.ca> a écrit: > >> >> Good article in the NYT: >> >> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business >> >> > > I surely gonna be blamed for saying this, however what can be noted > here, is that a [political] movement which is always shouting at > commercial companies is at the same time always expecting funds from > them. How can you one be serious expecting the end of something while > organizing a dependency on this thing? Also, and that's not a surprise, > nothing is expected from “ordinary users”, who do benefit as much from > unsupported/unpaid jobs as commercial companies do. > > People should stop believing in miracles and magic formulas and become > responsible (all the people, not just the commercial companies as a well > know political movement suggest). > > There is nothing one can get for strictly nothing (for a little fee may > be practical, but not for strictly nothing), even with software (which > is not just a matter of copying files as a well known movement wants to > make people believe). I hope someone will be able to bring back basic > economic principles in this area some day in the future. Another article in the NYT contrasts SSL to Linux. It points out that the Linux foundation (of which St. Linus is a key employee) gets over $6M / year in corporate funding (s. Wikipedia). http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects Linux is a pretty reliable and solid OS. Having "one Master" (Torvalds seems to still be the kernel merge master) and funding obviously helps. https://en.wikipedia.org/wiki/Linux_Foundation#Members & Funding -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:21 ` Alan Browne @ 2014-04-19 16:46 ` Georg Bauhaus 2014-04-19 19:22 ` Alan Browne 2014-04-19 16:50 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 16:46 UTC (permalink / raw) On 19/04/14 18:21, Alan Browne wrote: > Linux is a pretty reliable and solid OS. Having "one Master" (Torvalds seems to still be the kernel merge master) and funding obviously helps. What is the evidence of "obvious" here? I'm not denying that something may be the case. However, using "obvious" is either political rhetoric, or else one of the lesser habits of mathematical style: Some masters drive things against walls. Costly. Others succeed in getting really good things done. Why is that? What is "obvious" here? (You may have heard of the continuing failures to build BER airport. In spite of good ideas, good engineers, etc., something is wrong somewhere. Obvious?) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:46 ` Georg Bauhaus @ 2014-04-19 19:22 ` Alan Browne 2014-04-19 20:33 ` Georg Bauhaus 0 siblings, 1 reply; 44+ messages in thread From: Alan Browne @ 2014-04-19 19:22 UTC (permalink / raw) On 2014.04.19, 12:46 , Georg Bauhaus wrote: > On 19/04/14 18:21, Alan Browne wrote: >> Linux is a pretty reliable and solid OS. Having "one Master" >> (Torvalds seems to still be the kernel merge master) and funding >> obviously helps. > > What is the evidence of "obvious" here? I'm not denying > that something may be the case. However, using "obvious" is either > political rhetoric, or else one of the lesser habits of mathematical > style: > > Some masters drive things against walls. Costly. Others succeed in > getting really good things done. Why is that? What is "obvious" here? > > > (You may have heard of the continuing failures to build BER airport. > In spite of good ideas, good engineers, etc., something is wrong > somewhere. Obvious?) I'm sorry if I'm not up to your strict standard of language use - what I wanted to point out is that Linux (kernel) has many maintainers but a narrow choke point to release in the form of Mr. Torvalds (and/or his team). That - for the time being - helps drive reliability. It does not imply that that model will work for all endeavours, or that it can be copied as is. What it does imply is that a single-point-of-care-and-release would make for the possibility of stricter control over what can be released - following appropriate change control, requirements definition, testing and so on. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 19:22 ` Alan Browne @ 2014-04-19 20:33 ` Georg Bauhaus 2014-04-19 21:10 ` Alan Browne 0 siblings, 1 reply; 44+ messages in thread From: Georg Bauhaus @ 2014-04-19 20:33 UTC (permalink / raw) On 19/04/14 21:22, Alan Browne wrote: > What it does imply is that a single-point-of-care-and-release would make for the possibility of stricter control over what can be released - following appropriate change control, requirements definition, testing and so on. IOW, the bazaar may need a cathedral. Agreed. (Is anyone up for throwing the dialectic synthesis of these topoi into the press as a development of Raymond's idea?) ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 20:33 ` Georg Bauhaus @ 2014-04-19 21:10 ` Alan Browne 0 siblings, 0 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 21:10 UTC (permalink / raw) On 2014.04.19, 16:33 , Georg Bauhaus wrote: > On 19/04/14 21:22, Alan Browne wrote: >> What it does imply is that a single-point-of-care-and-release would >> make for the possibility of stricter control over what can be released >> - following appropriate change control, requirements definition, >> testing and so on. > > IOW, the bazaar may need a cathedral. Agreed. Yes. I've avoided that comparison but it's sort of right. OTOH, his "19 lessons" do not fit well into disciplined, deliberate, software engineering processes for infrastructure (internet). > (Is anyone up for throwing the dialectic synthesis of these > topoi into the press as a development of Raymond's idea?) -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:21 ` Alan Browne 2014-04-19 16:46 ` Georg Bauhaus @ 2014-04-19 16:50 ` Yannick Duchêne (Hibou57) 2014-04-19 19:25 ` Alan Browne 1 sibling, 1 reply; 44+ messages in thread From: Yannick Duchêne (Hibou57) @ 2014-04-19 16:50 UTC (permalink / raw) Le Sat, 19 Apr 2014 18:21:32 +0200, Alan Browne <alan.browne@freelunchvideotron.ca> a écrit: > > Another article in the NYT contrasts SSL to Linux. It points out that > the Linux foundation (of which St. Linus is a key employee) gets over > $6M / year in corporate funding (s. Wikipedia). > > http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects > I've seen this interesting article already after you posted it before. This is still not OK in many ways (I have reproaches to both Torvald and Linux for desktop), but I won't tell more (that's an Ada newsgroup here after all, not a general software or software economy newsgroup). Thanks for sharing anyway :-P . -- “Syntactic sugar causes cancer of the semi-colons.” [1] “Structured Programming supports the law of the excluded muddle.” [1] [1]: Epigrams on Programming — Alan J. — P. Yale University ^ permalink raw reply [flat|nested] 44+ messages in thread
* Re: OpenSSL development (Heartbleed) 2014-04-19 16:50 ` Yannick Duchêne (Hibou57) @ 2014-04-19 19:25 ` Alan Browne 0 siblings, 0 replies; 44+ messages in thread From: Alan Browne @ 2014-04-19 19:25 UTC (permalink / raw) On 2014.04.19, 12:50 , Yannick Duchêne (Hibou57) wrote: > Le Sat, 19 Apr 2014 18:21:32 +0200, Alan Browne > <alan.browne@freelunchvideotron.ca> a écrit: >> >> Another article in the NYT contrasts SSL to Linux. It points out that >> the Linux foundation (of which St. Linus is a key employee) gets over >> $6M / year in corporate funding (s. Wikipedia). >> >> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects >> >> > > I've seen this interesting article already after you posted it before. > This is still not OK in many ways (I have reproaches to both Torvald and > Linux for desktop), but I won't tell more (that's an Ada newsgroup here > after all, not a general software or software economy newsgroup). Linux is a GREAT OS. Linux sucks for desktop users. Ça va comme ça? > > Thanks for sharing anyway :-P . Of course. -- "Big data can reduce anything to a single number, but you shouldn’t be fooled by the appearance of exactitude." -Gary Marcus and Ernest Davis, NYT, 2014.04.07 ^ permalink raw reply [flat|nested] 44+ messages in thread
end of thread, other threads:[~2014-04-23 8:20 UTC | newest] Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-19 14:31 OpenSSL development (Heartbleed) Alan Browne 2014-04-19 15:06 ` Nasser M. Abbasi 2014-04-19 15:41 ` Alan Browne 2014-04-19 15:36 ` Georg Bauhaus 2014-04-19 16:00 ` Yannick Duchêne (Hibou57) 2014-04-19 16:34 ` Georg Bauhaus 2014-04-19 17:06 ` Yannick Duchêne (Hibou57) 2014-04-19 19:13 ` Georg Bauhaus 2014-04-19 20:39 ` Yannick Duchêne (Hibou57) 2014-04-19 19:42 ` Alan Browne 2014-04-21 23:51 ` Randy Brukardt 2014-04-22 15:20 ` G.B. 2014-04-22 16:33 ` Dmitry A. Kazakov 2014-04-22 16:57 ` Simon Clubley 2014-04-22 19:53 ` Dmitry A. Kazakov 2014-04-22 20:49 ` Yannick Duchêne (Hibou57) 2014-04-23 5:38 ` Natasha Kerensikova 2014-04-23 7:30 ` Dmitry A. Kazakov 2014-04-23 7:40 ` Natasha Kerensikova 2014-04-23 8:04 ` Dmitry A. Kazakov 2014-04-23 8:20 ` Georg Bauhaus 2014-04-23 7:42 ` Egil H H 2014-04-23 8:06 ` Georg Bauhaus 2014-04-19 16:06 ` Alan Browne 2014-04-19 16:42 ` Georg Bauhaus 2014-04-19 16:59 ` Georg Bauhaus 2014-04-19 19:12 ` Alan Browne 2014-04-19 20:20 ` Georg Bauhaus 2014-04-19 20:53 ` Alan Browne 2014-04-19 21:10 ` [OT] OpenBSD, was: " Simon Clubley 2014-04-19 21:53 ` Alan Browne 2014-04-19 22:15 ` Nasser M. Abbasi 2014-04-19 22:34 ` Alan Browne 2014-04-20 8:17 ` Georg Bauhaus 2014-04-20 16:49 ` Alan Browne 2014-04-22 12:18 ` G.B. 2014-04-19 15:47 ` Yannick Duchêne (Hibou57) 2014-04-19 16:21 ` Alan Browne 2014-04-19 16:46 ` Georg Bauhaus 2014-04-19 19:22 ` Alan Browne 2014-04-19 20:33 ` Georg Bauhaus 2014-04-19 21:10 ` Alan Browne 2014-04-19 16:50 ` Yannick Duchêne (Hibou57) 2014-04-19 19:25 ` Alan Browne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox