Talk:Heartbleed

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing / Security (Rated GA-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer Security (marked as Top-importance).
 
WikiProject Internet (Rated GA-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 GA  This article has been rated as GA-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 

Dissertation of the Programmer[edit]

What strikes me is the fact that the programmer in his Ph.D. explicitely mentioned the possibility to exploit the payload mechanism which he himself had implemented just before:

"The HeartbeatResponse must contain the same payload as the request it answers, which allows the requesting peer to verify it. This is necessary to distinguish expected responses from delayed ones of previous requests, which can occur because of the unreliable transport. The padding, on the contrary, always has to be of random data and is not sent back. The length of the padding is arbitrary, but should always be 16 bytes or more for security reasons, to prevent statistical attacks in case the payload is predictable. This can be the case if an implementation only uses sequence numbers for the payload of its requests. Without additional random bytes this payload can be guessed easily, thus making it prone to a KnownPlaintext Attack (KPA) [94]." [1], p.67

I tried to find a formulation to express this striking coincidence which might lead to the impression that the programmer was well aware about what he was contributing, although of course there could be other explanations as well. My contribution apparently sounded to biased to User:Per_Olofsson and he removed it. Please help me to find a wording neutral and subtle enough for WP:en, so that either interpretaion about deliberate intensions would be possible. I am not a native speaker in English so I might fail here. --HV (talk) 14:06, 13 April 2014 (UTC)

Thanks for your work! Someone will assist; others will further refine, if necessary. — Charles Edwin Shipp (talk) 16:51, 13 April 2014 (UTC)

Except that it is about the heartbeat feature he implemented, the quoted text has nothing to do with the bug. The discussed attacks are fundamentally different from the actual bug. No chance for conspiracy theories or original research.93.104.51.24 (talk) 21:32, 13 April 2014 (UTC)

But the excerpt shows at least that the developer being a security expert was very well concerned with the issue in which he himself had failed to be careful enough. How can this be explained? Serious lack of memory or concentration? Purpose? Other explanations? In any case it is an inevitable part of the whole scenario and thus should be mentioned in a reasonable and neutral fashion. --HV (talk) 21:43, 13 April 2014 (UTC)
Addition: neither conspiracy theory nor original research intended by me. Therefore I ask for collaboration. --HV (talk) 21:45, 13 April 2014 (UTC)

Explanation: He was blackmailed by the NSA but wanted give a secret hint about this in his dissertation by suggesting that he is a security expert worrying about security, since smart persons would know that such a person would never work on OpenSSL. Unfortunately, now since this section of his dissertation is public, the NSA will kill him before we can reveal details of this evil plot. Have a nice day! 93.104.42.169 (talk) 22:54, 13 April 2014 (UTC)

Even better explanation: he was forced by aliens to translate a portion of Nostradamus into code and a chapter of his dissertation... No, I don't want any speculation about inner or outer reasons for this coincidence, but rather a dry and short description of the fact, which might have a legion of possible reasons, including amnesia, simplemindedness and pure accident. It's the circumstances which matter here because they do give a perfect scenario for a potential social hack (regardless if it really happened or not). These circumstances are part of the story and of encyclopedic relevance. What will happen in the fantasy of our readers, even if some of them become paranoid, is none of our business. Did you get my point? --HV (talk) 05:16, 14 April 2014 (UTC)

As 93.104.51.24 notes, the passage you are quoting does not describe the actual bug at all. I am not sure what you think is suspicious about the quote, but it does not say anything about buffer overflows. Even if he did discuss buffer overflows in his thesis, I do not think it is appropriate to point out "coincidences" on Wikipedia like that. On the other hand, if you can find a reliable source that discusses this, then you could cite that source. Otherwise I think it constitutes original research. (And in this case I believe you are mistaken, but that is beside the point.) --Per Olofsson (talk) 09:51, 14 April 2014 (UTC)

I should also note, HV, that I do not think you are biased and I did not specifically object to the exact wording. I reverted your edit because I felt it constituted WP:OR, more specifically WP:SYNTH. If you can find a reliable source that discusses coincidences in the thesis regarding the Heartbleed bug, then I have no problem if you cite it on the page. However, in this case, I felt you were creating a synthesis by implying something that the source did not state. --Per Olofsson (talk) 10:18, 14 April 2014 (UTC)

I agree that this is irrelevant to the software bug. It is worth mentioning the padding requirement in the article about DTLS though, if that article gets expanded. 70.36.142.114 (talk) 15:26, 14 April 2014 (UTC)

"OpenSSL must die"[edit]

Git vulnerability[edit]

Current version of the article has this entry in the list of vulnerable appications: "git 1.9.1 tested clone / push, leaks not much". Git uses multiple ways of communication [3]. The article should specify which of those are affected.Muelleum (talk) 21:57, 15 April 2014 (UTC)

I don't think Git has an embedded http/s server. You put your repo under a separate web server that might or might not have the heartbleed bug. 70.36.142.114 (talk) 11:09, 16 April 2014 (UTC)

Copyright (attribution) problems[edit]

FYI: I've mentioned this article on WT:CP. --Muelleum (talk) 00:44, 16 April 2014 (UTC)

Removing XKCD[edit]

Regrettably, I am removing the XKCD 1354 explanation of the bug. We really can't replace a suitably licensed drawing with non-free content and then claim that "no free equivalent is available, or could be created, that would serve the same encyclopedic purpose." as our policy WP:NFCC demands in criteria 1. Furthermore, the reduced resolution image that was uploaded isn't even legible. If it were up to me, I'd allow NC content and tag it so commercial users would be warned not to copy it, but it is not up to me and attempts to change the policy have failed in the past. Maybe the author could be persuaded to release this strip under a compatible license, but absent that it can't stay.--agr (talk) 10:17, 18 April 2014 (UTC)

That's insane. If we created a free equivalent of the XKCD comic, we would be ripping them off, thus violating their copyright. I would think that XKCD would want credit for their work, and that we not rip them off, which is apparently what you are saying.
No offense to you personally, ArnoldReinhold, I'm sure you're acting in good faith. A Quest For Knowledge (talk) 10:38, 19 April 2014 (UTC)
Further, it's published under this license which says that we are free to copy and redistribute the material in any medium or format as long as we give credit and we use it for non-commercial purposes. A Quest For Knowledge (talk) 11:15, 19 April 2014 (UTC)
I've added content sourced to third-party reliable sources to the article about this comic.[4] A Quest For Knowledge (talk) 12:03, 19 April 2014 (UTC)
The image may be considered freely licensed by common standards, but if the image does not allow for free commercial use, then it is considered non-free by Wikipedia's standards (which means the XKCD comic would have to meet the criteria for using non-free content, which it does not). ~SuperHamster Talk Contribs 19:00, 19 April 2014 (UTC)
Again, that's insane. I do not see that there is any way to replicate this comic without violating XKCD's copyright. Are we seriously suggesting that in order to protect XKCD's copyright, we must violate XKCD's copyright? If not, can someone please provide a free equivalent graphic that of the XKCD comic withhout violating their copyright? A Quest For Knowledge (talk) 19:34, 19 April 2014 (UTC)
Who said anything about replicating the comic? The point is that Heartbleed can be perfectly explained through just text, or with another sort of graphic, such as this one that does a great job of explaining the bug much more compactly than the XKCD comic. No one said anything about creating a duplicate version of the XKCD comic. ~SuperHamster Talk Contribs 20:08, 19 April 2014 (UTC)
However, compact does not mean understandable by the non-technical user. That is the beauty of Randal Munroe's comic. It explains Heartbleed simply and elegantly to the non-technical user. With all due respect, File:Heartbleed bug explained.svg just does not do it for me nearly as well, & I have been working in I.T. for nearly a ¼ century.
Going back to another part of this discussion, I think the relevant guidelines can be found at WP:FAIRUSE & a section of that page, WP:Image resolution.
The strict interpretation of WP:IMAGERES is "At the low pixel count end of the range, most common pictorial needs can be met with an image containing no more than about 100,000 pixels (0.1 megapixels)." I attempted to do that at File:Xkcd - Heartbleed Explanation by Randall Munroe.png with a 216 × 460 (82 KB) image. While that was largely unreadable at that low resolution, my main intent was to drive traffic to the comic where it could be freely viewed as the creator, Randall Munroe, intended. However, a subsequent author removed it.
In any case, File:Xkcd.com-1354-how-the-heartbleed-bug-works.png needs a {{Non-free use rationale}} template placed in the summary, such as the one at File:Xkcd - Heartbleed Explanation by Randall Munroe.png. It might even be best to use the earlier existing file & Upload a new version of this file since that file & its discussion precedes the File:Xkcd.com-1354-how-the-heartbleed-bug-works.png file.
Peaceray (talk) 20:28, 19 April 2014 (UTC)
Re "my main intent was to drive traffic to the comic" - hmm, what to do, what to do, what to do ... WP:NOTPROMO is a policy, but so is WP:IAR.
I'm sure your real intent was to improve the article by adding educational material, right??? Right??? Face-smile.svg davidwr/(talk)/(contribs) 21:06, 19 April 2014 (UTC)
My real interest is to raise awareness about this vulnerability, including among non-technical audiences. Given WP:IMAGERES calls for "no more than about 100,000 pixels", & that going to that resolution leaves it illegible for nearly all, the best that I could hope for was to use the graphic to indicate "hey, there's is something worth looking at here." The comic is a simple & elegant non-technical explanation of the Heartbleed vulnerability & how it is exploited. Getting peiople to read it is in the public interest. WP:NOTPROMO would not even play into this if WP:IMAGERES allowed a readable image. Peaceray (talk) 23:13, 19 April 2014 (UTC)
Regardless, I still fail to see how the use of the comic meets non-free content criteria, particularly points 1 and 8. The free comic I linked to earlier does serve as a free equivalent, per OP. If it doesn't, well, a better one could certainly be created. Its presence may help with the understanding of the subject, but its omission is definitely not detrimental to the understanding of the subject, either, when free alternatives (or simply explaining the bug through text) will suffice. ~SuperHamster Talk Contribs 21:47, 19 April 2014 (UTC)
I have seen no free alternatives that are nearly as simple & elegant an explanation for non-technical audience as the xkcd: Heartbleed Explanation comic. Many more people would quickly grasp what Heartbleed does than through the technical explanations in the article. The free content graphic File:Heartbleed_bug_explained.svg is not nearly as lucid.
You state that if the free comic that you linked to earlier does not serve well as a free equivalent, then a better one could certainly be created. Well, get at it!
Peaceray (talk) 23:40, 19 April 2014 (UTC)
To be honest, the current graphic does look a bit Microsoft painty. I could try putting together a more polished one. – FenixFeather (talk)(Contribs) 00:35, 20 April 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Here's a rough draft of a simplified version of the graphic I've done so far, integrating the content of the original graphic with the conversation style of the xkcd comic. Let me know what you think.

svg version (Should be easy to edit with Inkscape)

raster version

FenixFeather (talk)(Contribs) 01:06, 20 April 2014 (UTC)

Wikipedia like thumb.png
I like the raster version! Peaceray (talk) 02:13, 20 April 2014 (UTC)
Oops, yeah I think the svg version doesn't work well in browsers (it should look identical to the rasterized version). I'll have to flatten the layers before uploading, if we decide to use the picture. The server graphic might need some more detail too. – FenixFeather (talk)(Contribs) 02:35, 20 April 2014 (UTC)

Simplified Alternative[edit]

So after a lot of problems I've finally managed to upload a proper svg to commons. Let me know what you all think! – FenixFeather (talk)(Contribs) 03:20, 20 April 2014 (UTC)

Example alt text
Simplified Heartbleed explanation
I think it's good, but you need to label both 'Server' and the 'Client'. Then it'll be perfect. Tutelary (talk) 04:28, 20 April 2014 (UTC)
Thanks for the feedback. I'll add it. – FenixFeather (talk)(Contribs) 04:31, 20 April 2014 (UTC)
Would be good to have some text inside the server box, as in the XKCD cartoon, to illustrate where exactly this "secret server info" is coming from. Bigger text to make it more thumbnail-legible would help, too. But the current version is already much clearer than the existing user-made cartoon - I'll add it to the article. --McGeddon (talk) 10:32, 20 April 2014 (UTC)
Looks great, well done guys :) ~SuperHamster Talk Contribs 12:45, 20 April 2014 (UTC)
Thanks!! I've made the text bigger and added server text per your suggestions. – FenixFeather (talk)(Contribs) 17:23, 20 April 2014 (UTC)
Heartbleed can in fact affect a client, not just servers. I would therefore suggest more generic labels - perhaps "Vulnerable party" on one end and "Unmalicious/Legitimate/Harmless/? party" and "Malicious party" on the other. By the way, I find the size of circles out of proportion. If easy, I'd appreciate to see them smaller. --Chealer (talk) 19:34, 29 April 2014 (UTC)
That is stated in the body of the article. The picture merely provides an example of a Heartbleed request; it is not intended to describe Heartbleed in its entirety. Thus it is more useful to arbitrarily assign the attacking party to a user and the victim as the server without loss of generality, especially because normal Heartbleed is much more dangerous and received more coverage in reliable sources than reverse Heartbleed. I enlarged everything so that the thumbnail would be more visible. – FenixFeather (talk)(Contribs) 20:27, 29 April 2014 (UTC)

Table Alternative[edit]

Here is the same content (give or take a few minor details) as a table:
Heartbleed in action, as a table
Normal Heartbeat
Comment alt font awesome.svg Server, send me this 4 letter word if you are there: "Blah"  
"Blah" Speech bubble for Wikipedia messages 2014-01-15 18-42.png
Heartbleed
Comment alt font awesome.svg Server, send me this 16,004 letter word if you are there: "Blah"  
"Blahabc123dfsaUsername:JimboPassword:Wales...." Heartbleed.svg
davidwr/(talk)/(contribs) 04:22, 20 April 2014 (UTC)

Looking pretty good. But with the above image, there needs to be a label on what is what. Tutelary (talk) 04:29, 20 April 2014 (UTC)

  • I like this. Perhaps we could add some icons so that casual readers understand what each party is. Perhaps something like Computer.svg and Server-tower.svg. Mahahahaneapneap (talk) 12:35, 22 April 2014 (UTC)

earlier bug[edit]

Might be worth mentioning this: https://www.debian.org/security/2008/dsa-1571

It was worse than Heartbleed in some ways, it affected a heck of a lot of systems (not as many as Heartbleed but still a lot), but it didn't have the marketing campaign so nobody remembers it now. 70.36.142.114 (talk) 11:43, 18 April 2014 (UTC)

Lessons Learned by Internet users[edit]

I like the last paragraph that explains what providers (hardware and software) have learned from the Heartbleed stealth and evil attack. But there are also lessons that could be noted concerning what Internet users have learned. How can we be more vigil? What have we learned? A new concluding section could be added, or noted elsewhere in the article herein. — Charles Edwin Shipp (talk) 01:01, 20 April 2014 (UTC)

An example: Wikipedia is on the 'affected' list. What I've learned is to logout and disconnect my ethernet cable. The option upon logging in to Wikipedia, "Stay connected for 30 days" is not a good option, in my opinion. Charles Edwin Shipp (talk) 19:30, 21 April 2014 (UTC)

The concluding paragraph is bogus[edit]

The concluding paragraph is bogus. There are tons of bugs in proprietary software too.[5] OpenSSL is rather crufty though. The OpenBSD team is overhauling it, but who know if the extensive changes will introduce more bugs. Best practice is probably to use the "engine" feature to put the sensitive crypto operations into a separate process, and there's at least one big installation planning to move to that approach, but I don't have an RS for that yet. There may be some general security principles we can quote from, e.g. from Ross Anderson's book. [6] 70.36.142.114 (talk) 03:04, 20 April 2014 (UTC)

Let's fix it. — Charles Edwin Shipp (talk) 14:18, 21 April 2014 (UTC)
Prior to the concluding paragraph, I'd like to see an additional section, "Lessons Learned by Internet users". Charles Edwin Shipp (talk) 19:34, 21 April 2014 (UTC)
Resolved
The offending paragraph has been removed.
Otherwise, the section already discusses some technicalities, but feel free to expand. --Chealer (talk) 07:21, 1 May 2014 (UTC)

Heartbleed certificate revocation[edit]

I've reverted this good faith edit because the explanation ("does not actually test whether Heartbleed is present on a given site") doesn't apply to what the test does. Of course, it doesn't address whether Heartbleed isn't on any particular site. That's not what it does. Instead, it tests whether a browser checks whether an SSL certificate has been revoked. Heartbleed allows hackers to steal SSL certificates. Even if the website revokes the stolen certificate, if the browser doesn't check whether it was revoked, the browser will report the revoked certificate as legitimate. This test was specifically created because of the Heartbleed bug. According to Netcraft, only 30,000 of the 500,000+ SSL certificates affected by the Heartbleed bug have been reissued up until today, and even fewer certificates have been revoked.[7] A Quest For Knowledge (talk) 02:08, 20 April 2014 (UTC)

Meh, Adam Langley argues that online CRL checking is useless.[8] Yes revocation is appropriate but I wouldn't get that worked up about it. 70.36.142.114 (talk) 03:42, 20 April 2014 (UTC)
I do not consider this test as relevant in this article. However, if some people think it is, keep in mind it doesn't "test whether Heartbleed affects a given site", which is the reason why I am removing it. --Chealer (talk) 17:41, 20 April 2014 (UTC)
It's certainly wrong to call it a check for heartbleed. However, lots of heartbleed-affected sites have been replacing their certificates (and sometimes revoking the old ones), so mentioning something about that is relevant to the article, at which point it's reasonable to point to a CRL checking tool. 70.36.142.114 (talk) 18:15, 20 April 2014 (UTC)
@Chealer: It doesn't matter whether you personally think it's relevant to the article. Original reseach isn't allowed and even if it was, you would be wrong. The fact remains that a hacker can steal a web site's certificate using Heartbleed and this tests whether the web site's certificate has been revoked. If you don't understand how Heartbleed works, maybe you shouldn't be editing this article. A Quest For Knowledge (talk) 19:21, 20 April 2014 (UTC)
A Quest For Knowledge, I fail to see why you allude to OR. My edit simply removes material. In any case, as I wrote, the reason why I removed the material is because it made the section wrong, not because I consider it irrelevant. --Chealer (talk) 19:50, 20 April 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Wait, what are you guys arguing about? AQFN, what edit did you revert at the top of the section? I remember seeing a CRL checker mentioned in the section about heartbleed tests. I'd say a CRL checker is definitely not a heartbleed test and should not be described as one, but it's arguably relevant to the article anyway, so there is a case for including it as part of info about cert revocation. Cert revocation itself should be mentioned in the article (including whatever sourcing can be found about whether it's a good or bad idea) since it's being recommended by some as a response to Heartbleed. Actually, if anyone has a revoked certificate that they can still serve, it might be interesting to show a screen shot of a browser responding to an OCSP failure. 70.36.142.114 (talk) 19:41, 20 April 2014 (UTC)

If it's just a question of placement, I've moved it out of the list. Hopefully, this addresses Chealer's concerns. A Quest For Knowledge (talk) 06:11, 21 April 2014 (UTC)
Resolved
It does, thanks. --Chealer (talk) 07:28, 1 May 2014 (UTC)

reverse heartbleed[edit]

Anyone wanting to add the above, please feel free. I may not get a chance to do it today, and I'll probably be offline for several days starting in a few hours. 70.36.142.114 (talk) 19:35, 20 April 2014 (UTC)

Often, blogs require additional supporting documentation. — Charles Edwin Shipp (talk) 14:27, 21 April 2014 (UTC)

Cost[edit]

It would be interesting to include an approximation of the cost of Heartbleed. According to [9], "Even if there hasn’t been any malicious exploitation of the bug, the costs of people’s time will likely run into the hundreds of millions of dollars." There aren't details on how that was computed. I wonder if this is realistic. --Chealer (talk) 20:07, 20 April 2014 (UTC)

That number is pretty speculative but not completely crazy imho. You could compute as 500k sites spending 2 hours each dealing with upgrades and cert replacement at $100 an hour = $100 million. More likely though, most of those sites will just do a standard update and not bother replacing their certs, and in most cases nothing will happen if they did it soon enough. Then there will be some unpatched sites that suffer actual cert theft, and a small fraction of those will have some sessions compromised through MITM attacks on (e.g.) public wifi networks, causing more hassles. I think large scale MITM attacks are less likely. Then there may also be client compromises from malicious servers (see "reverse heartbleed" above) etc. The article linked is reasonably good. 70.36.142.114 (talk) 20:48, 20 April 2014 (UTC)
Failing a better source, I've added a very rough estimation of 500 million USD from eWEEK. I'd love to see a real calculation replace that. --Chealer (talk) 02:02, 24 April 2014 (UTC)

Original research[edit]

I've removed this[10] for a number of reasons. First of all, it is original research to connect it to this article's topic. It doesn't even mention Heartbleed. See WP:SYN. Second, it is poorly sourced. Citing press releases is usually not a good idea. Instead we should rely on third-party reliable sources which have a reputation for accuracy and fact-checking. Third, it is out of date and was written before Heartbleed. A Quest For Knowledge (talk) 06:08, 21 April 2014 (UTC)

I think this should be a pretty noncontroversial removal. It seems quite obvious that the content was added as an originally researched counterargument to the preceding claim. – FenixFeather (talk)(Contribs) 07:06, 21 April 2014 (UTC)
I'd be inclined to throw out the whole paragraph based on the article by Damien Choizit. Mr. Choizit's article seems to be a lot of platitudes but without much in the way of hard facts. And anyone who considers "open-source code" and "outsourced code" to be the same or similar doesn't know what he's talking about. RenniePet (talk) 13:52, 21 April 2014 (UTC)
He seems to conflate open source and nonproprietary too. In any case, I think the paragraph is a bit too long and redundant. It could be reduced to one sentence saying "It has also been suggested that because OpenSSL is developed by volunteers, it has not undergone the rigorous testing that proprietary software would undergo." or something. No need to mention this guy by name multiple times when we don't even know how he's connected or especially qualified to talk about the issue. – FenixFeather (talk)(Contribs) 14:06, 21 April 2014 (UTC)
Please do it, thanks.RenniePet (talk) 15:57, 21 April 2014 (UTC)
Resolved
It may be possible to shorten the paragraph but the suggestion is inappropriate. The implication that proprietary software undergoes rigorous testing would have required sourcing. Furthermore, while we may not need multiples mentions of the author, I oppose to removing all mentions. The current formulation is a bit shorter but much vaguer, suggesting that many may have suggested that conclusion while we only know of one person who has. I prefer the previous version or no paragraph to that short form. I am going for no paragraph to avoid controversy, considering the source's limited reputation, the suggestion's weakness, and considering that the section already offers several other explanations. --Chealer (talk) 23:33, 21 April 2014 (UTC)
Coverity is a third-party source with regard to this article. The statement is not "out of date" just because it wasn't published this year, unless there are hints of an unlikely fast change in the area. The mention does not constitute original research. There is no need for everything in this article to be ulterior to Heartbleed's disclosure. Choizit's argument is a generalization from Heartbleed/OpenSSL to open-source is general. Such a generalization can be questioned and will inevitably be with the debate around this controversial topic (which we cover very briefly in [11]). This topic is old and has obviously been debated years before Heartbleed. Heartbleed's disclosure does not make all anterior material obsolete.
There is one issue with the statement's relevance - it is focused on C. While Heartbleed is written in C, proprietary equivalents could be written in safer languages, which would reduce the likeliness of equivalent vulnerabilities. I believe C is indeed overrepresented in free software, weakening the report's relevance, but I do not think this suffices to completely ignore the findings. --Chealer (talk) 23:33, 21 April 2014 (UTC)

Latest Current new News[edit]

Headine-1: Heartbleed Will Require Rehab

QUOTE: “Security experts worldwide have deemed the so-called Heartbleed bug one of the most dangerous security flaws ever to crop up on the Web. While we don't know the full extent of Heartbleed's menace, the bug has the potential to cause catastrophic data breaches. When news of Heartbleed broke, Internet users were advised to change all their online passwords as a precaution, and enterprise IT security teams scrambled to neutralize the immediate threat by applying a patch. But like many serious conditions, the real danger posed by the Heartbleed bug is longer term and much more quiet than the initial hoopla might suggest. ” ["Patches are just band-aids. Heartbleed's long-term effects will force companies to reassess how they deploy and manage technology."] — Charles Edwin Shipp (talk) 14:24, 21 April 2014 (UTC) — PS: FYI for future editing.

Headine-2: Why Heartbleed May be more Troubling for Healthcare.gov in the Long Run

QUOTE: “Users of HealthCare.gov are being asked to change their passwords due to the federal exchange’s potential vulnerability to the Heartbleed security flaw, and the warning is troubling, analysts say, as medical information is hotter than ever for criminals looking to make a quick profit.” [Helathcare.gov and relating Obamacare websites and methodologies were never known for tight security!] — Charles Edwin Shipp (talk) 00:27, 23 April 2014 (UTC) — PS: FYI for future editing.

Headine-3: The U.S. Needs to Stop Running Internet Security Like a Wikipedia Volunteer Project

QUOTE: “ One lesson of the Heartbleed bug is that our government is paying to undermine Internet security, not to fix it.” [Comment-1: The left-handed compliment to Wikipedia is interesting; Comment-2: There is more to security than passwords—such as encrypted-transmission. Comment-3: This article is headlined for Google News; Comment-4: The last paragraph of the Article herein (WP) covers this aspect, to some extent.] — Charles Edwin Shipp (talk) 11:54, 23 April 2014 (UTC) — PS: FYI for future editing.

Security Now[edit]

I just wanted to mention that Security Now has been providing some excellent, in-depth coverage of this topic:

A Quest For Knowledge (talk) 23:15, 23 April 2014 (UTC)

Lastpass request for reference[edit]

Lastpass, the company, owns Lastpass Password Manager. It was from a direct blogpost from them, describing that Lastpass Password Manager was vulnerable. Per WP:PRIMARY, this is a sufficient reference, and we do not need another one. Also, the entries below it use primary sources as well, and I don't see you tagging them as 'needing another reference'. Specific text; A primary source may only be used on Wikipedia to make straightforward, descriptive statements of facts that can be verified by any educated person with access to the primary source but without further, specialized knowledge.. Tutelary (talk) 22:19, 25 April 2014 (UTC)

I agree. The repeated insistence on reference is very odd. I just read the entire blog post and it seems to support the article text pretty well. We indicate that Lastpass's service was affected, but that they had measures in place that prevented further damage. I don't see any conceivable reason that the source does not support the article text. – FenixFeather (talk)(Contribs) 03:31, 26 April 2014 (UTC)
As I already explained, the reason for the tag isn't that a "better source" is needed (although [12] did imply that). What is missing is a source for the part of the paragraph stating that LastPass Password Manager was vulnerable. As previously explained, a source stating that LastPass was vulnerable does not suffice to claim that LastPass Password Manager was vulnerable, just like a claim that Microsoft was affected wouldn't suffice to claim that Microsoft Windows was affected (although LastPass Password Manager probably has more relative importance to LastPass than Microsoft Windows has to Microsoft).--Chealer (talk) 20:36, 26 April 2014 (UTC)
It is very much sufficient. Two editors (including myself) are against you, and per WP:CONSENSUS, and in accordance with WP:EDITWAR, you should not be readding content that one or more editors disagree with (when you know they disagree) with it. Per WP:PRIMARY, It is a sufficient enough source. We don't need a better source than the company themselves. The source stating themselves are vulnerable is by themselves. Also, you're not giving the source enough WP:DUE. It's the company's official blog. If that's not reliable, I don't know what is. Is your final goal to remove the Lastpass section entirely, due to being properly sourced as you did once before?: https://en.wikipedia.org/w/index.php?title=Heartbleed&diff=605482274&oldid=605482150 Tutelary | It should also be noted that the sources below Lastpass (and above) also rely on primary sources, yet I don't see you ultimately tagging them. What is missing is a source for the part of the paragraph stating that LastPass Password Manager was vulnerable. As previously explained, a source stating that LastPass was vulnerable does not suffice to claim that LastPass Password Manager was vulnerable, just like a claim that Microsoft was affected wouldn't suffice to claim that Microsoft Windows was affected (although LastPass Password Manager probably has more relative importance to LastPass than Microsoft Windows has to Microsoft). No. Not another source is needed. An official statement by Microsoft meets WP:DUE and we would include it, as they are the owner of the software and know it better than anybody else. I'd also like to request on what policy you think that this is not a reasonable source to use for a claim about their product which they own. Tutelary (talk) 00:15, 27 April 2014 (UTC)
WP:CONSENSUS does not claim that one shouldn't readd content because one knows of an opposing editor. In any case, I have not readded content. This has nothing to do with WP:PRIMARY. We couldn't include a claim that Microsoft Office was affected just because a source (even if it was Microsoft) would claim that Microsoft was affected. Do you understand that Microsoft and Microsoft Office are not the same thing? My final goal is to make the article comply with our guidelines, whether that's by removal of unverifiable content or by proper sourcing. --Chealer (talk) 17:15, 27 April 2014 (UTC)
We would give it its WP:DUE to it being an official source, and the owner of the software. Yes, we would very much include it. You still have not linked to a policy regarding this. Tutelary (talk) 17:33, 27 April 2014 (UTC)
Again, this has nothing to do with ownership of the software. No matter how much boldface or textual effects you want to use, we still won't consider it as verifiable that Microsoft Office is foo just because the best source in the world says Microsoft is foo. If you need a link to get that point, then see Wikipedia:Verifiability. --Chealer (talk) 02:27, 28 April 2014 (UTC)
Why is that page not sufficient? It's talking about their product. They refer to their own product as LastPass. See this. It doesn't even make sense for a company to be vulnerable to Heartbleed. – FenixFeather (talk)(Contribs) 22:31, 26 April 2014 (UTC)
Just to add to numbers without discussion, I agree that the LastPass information (which I also have edited) is sufficient. I edited it to the wording "According to the LastPass Password Manager blog, a standard test showed it as being vulnerable until it was patched on 8 April but, due to its use of additional encryption and forward secrecy, potential attacks were not able to exploit this bug. However, LastPass recommended that users change passwords that LastPass stored for vulnerable websites." This was changed, I don't know if because someone disagreed, or as a side-effect of other changes. My intention was to give more detail and stay close to the source: "a standard test showed it as being vulnerable" (from the Web page). The present wording "LastPass Password Manager, according to the company's official blog, showed it as being vulnerable" is perhaps not quite right (a particular test flagging it as vulnerable doesn't mean it actually was; it is claimed that it wasn't, actually) and ungrammatical. Pol098 (talk) 11:01, 27 April 2014 (UTC)
Pol098, I was the one who reworded it to match the style of wording listed by the other products. All of them had their names listed as first, so I sought to do the same for Lastpass. I've restored the original wording except for a few words. You have my blessing to restore it entirely if you still don't think it's right. Just keep in the mind the style that the other entries have. They start with their names first, so if you do change it, try to preserve that. Tutelary (talk) 12:48, 27 April 2014 (UTC)
Thanks for explanation. I see it's been reworded now (I got an edit conflict when doing it myself!); I think it's better that way. Best wishes, Pol098 (talk) 14:13, 27 April 2014 (UTC)
According to LastPass Password Manager, their product is known as "LastPass Password Manager". It does make sense for a physical or moral person to be vulnerable to an exploitation of Heartbleed. --Chealer (talk) 17:15, 27 April 2014 (UTC)
Chealer, please do not readd the request for reference. There are now 3 editors against you, and I really hope you get it this time. You haven't addressed any of the points that I or anybody else have made. @Chealer:, I find it incredibly disruptive that you have to resort to misleading edit summaries to drive your point in; https://en.wikipedia.org/w/index.php?title=Heartbleed&diff=606059695&oldid=606059230 | The next time that you edit this section in without engaging in any rebuttals of the arguments here, I will go through the proper channels regarding this. Tutelary (talk) 17:26, 27 April 2014 (UTC)
There's no need to get adversarial. I'm not "against you", we simply disagree on one point (or more likely, one of us misunderstands something). I did answer some or all of the points. Please focus on participating in the discussion rather on than pushing your favorite version. --Chealer (talk) 17:33, 27 April 2014 (UTC)
It is not I who resorted to misleading edit summaries in order to secretly readd the request for reference tag against WP:CONSENSUS. Consensus is how we make editorial and content based decisions here on Wikiepdia. You are welcome to attempt to prove to the community that is is flawed, and needs a change but for now, the consensus is against you. Tutelary (talk) 17:34, 27 April 2014 (UTC)
Please assume that your colleagues act in good faith. There was an edit conflict and a change was lost. There is unfortunately no consensus at this point on this issue, but it would help if everyone could stay civil and pursue discussion rather than pursuing an edit war. --Chealer (talk) 02:27, 28 April 2014 (UTC)
Per WP:CIRCULAR, we should avoid using Wikipedia articles as sources, even in a discussion. The article itself may have to be moved, depending on more information on the official product name. In any case, even if only the informal name is Lastpass, it is very clear that when Lastpass says "Lastpass was vulnerable to Heartbleed," they mean their product, Lastpass, a password managing software, not the company. Using your Microsoft example, Microsoft cannot be vulnerable to Heartbleed. Maybe Microsoft services such as Skype and OneDrive can be vulnerable, but certainly not Microsoft itself. – FenixFeather (talk)(Contribs) 18:11, 27 April 2014 (UTC)
Not to mention that they regularly use "Lastpass" as the short version of their product. Tutelary (talk) 18:19, 27 April 2014 (UTC)
Microsoft can certainly be vulnerable to Heartbleed. If one of its systems is attacked, damages to these systems will be damages to Microsoft. The question is what the "product" is - a service or an application? Most likely a service, in which case the item needs another source.--Chealer (talk) 02:27, 28 April 2014 (UTC)
It is both. While the LastPass article may need to figure out what the article is on, in real life, when they say LastPass is vulnerable, they mean that the service, which includes the LastPass application, is vulnerable. Users of the LastPass service use the LastPass application to connect to LastPass servers, where they can store their information. – FenixFeather (talk)(Contribs) 04:28, 28 April 2014 (UTC)
I agree, their system must have a server and clients. The reference clearly refers to the service. Had it been about the application, they'd have mentioned vulnerable versions (and - hopefully for their customers - released a fixed client by now). --Chealer (talk) 15:45, 30 April 2014 (UTC)
The main lastpass application is web based which means that the server is the critical bit. Yes they have booklets and plugins for browsers etc. but the doesn't change that. PaleAqua (talk) 17:01, 30 April 2014 (UTC)
I'm not sure I get what you mean by the "main lastpass application". The application to manage passwords? Surely that application doesn't allow form filing :-? --Chealer (talk) 20:52, 30 April 2014 (UTC)

Chealer, I second those above who point out that a company can't be vulnerable to a SSL bug—only a particular web service, in this case Lastpass's password vault service, can. The official blog post seems perfectly clear to me—the servers running their service were initially vulnerable to the bug before being patched. I'm removing the "dubious" tag.—Neil P. Quinn (talk) 04:02, 28 April 2014 (UTC)

Yeah, I threw in another source that explicitly mentions them trying to fix their service on the 8th. Hopefully this will please him. He's been edit warring all sorts of tags into that part of the article. – FenixFeather (talk)(Contribs) 04:23, 28 April 2014 (UTC)
One might argue that only software can be "directly" vulnerable to a bug, but if we take "open to attack or damage" as the definition of "vulnerable", then an organisation can be vulnerable to Heartbleed ("indirectly", if you wish). Anyway, thanks for your opinion, that's also how I interpreted the source. Although we haven't been asking for a source blaming the application and specifics for very long, I'm taking their absence as a confirmation that these don't exist, and am moving the problematic piece. --Chealer (talk) 15:45, 30 April 2014 (UTC)

Password managers and recommendations[edit]

Note that fact that the passwords were stored in a particular vault doesn't matter in regards to vulnerabilities on other websites and so I removed what to me seems like a redundant bit of advice, which might better besides some other statements of recommendations of password changes. That said I like Tutelary's rewrite as it avoids the implication that it is the channel between lastpass and other sites that was the problem. That said we have several sentences and sources quoted as saying stuff like "People should take advice on changing passwords from the websites they use.", People should take advice on changing passwords from the websites they use., The following sites have services affected or made announcements recommending that users update passwords in response to the bug, Platform maintainers like the Wikimedia Foundation advised their users to change passwords. already spread though out the article, so it does feel a bit redundant to say just a few sentences similar sentences that same thing again. We also seem to be missing stuff that was covered by several sources about how such vaults help with recovery after such an incident? For example:

Tools are now widely available that will store and organise all your passwords and PIN codes for computers, apps and networks. They can also generate passwords and can automatically enter your username and password into forms on websites.
Such tools store your passwords in an encrypted file that is accessible only through the use of a master password. Examples of such services include KeePass, LastPass and 1Password.

If I recall there were several news articles extolling the virtues of such managers as part of there converge. PaleAqua (talk) 21:11, 30 April 2014 (UTC)

I would not be opposed to adding such material to the article, however it does border on the not an instruction manual policy of Wikipedia. Saying something like, "It is recommended that you use a password manager" I think would have no place. However maybe in a reception/section somewhere, say something like, "BBC recommended using a password manager in order to have secure passwords" or something like that. I don't know. It still appears somewhere promotional (even if others don't see it that way.) Anywho, I didn't exactly rewrite it. It was what it was before Chealer messed with it, so I just restored that version of it. Tutelary (talk) 21:18, 30 April 2014 (UTC)
Sorry didn't realize it was the same. True enough about sounding promotional. PaleAqua (talk) 21:38, 30 April 2014 (UTC)
I recognize that the sentence is correct, but I also support its removal, for reasons you mention. --Chealer (talk) 21:44, 30 April 2014 (UTC)
We are reporting what the source says. The discussion above was pertaining to a possibility of a new paragraph or sentence to the 'reception' portion of the article, and the possibility of creating one. Do not misinterpret this as approval to remove the sentence. Tutelary (talk) 21:46, 30 April 2014 (UTC)
If PaleAqua didn't support removal, I don't know how to interpret the following part:

That said we have several sentences and sources quoted as saying stuff like "People should take advice on changing passwords from the websites they use.", People should take advice on changing passwords from the websites they use., The following sites have services affected or made announcements recommending that users update passwords in response to the bug, Platform maintainers like the Wikimedia Foundation advised their users to change passwords. already spread though out the article, so it does feel a bit redundant to say just a few sentences similar sentences that same thing again.

Although I recognize that his comment doesn't constitute endorsement for removal like mine. --Chealer (talk) 21:01, 3 May 2014 (UTC)
While my preference did lean a bit towards removal, I actually like the idea of a slightly expanded reception portion. While wikipedia is not a how to guide, a number of sources did offer recommendations, and we should cover that. I've also heard that of numerous scams using heartbleed as the hook, might be worth mentioning ( though briefly ) as well. For example: Heartbleed Used by Identity Thieves in Phishing Scam; I know someone that almost got taken in by one that was similar to the "Microsoft/Windows Support" event viewer scam but based around Heartbleed. btw: her not his PaleAqua (talk) 21:16, 3 May 2014 (UTC)

Requesting periodic reassessment of "importance" for WikiProjects[edit]

Wikipedia:WikiProject_Internet/Assessment#Importance_scale gives Netscape Navigator as an example of a mid-importance article. There was a time that NS Navigator was the web browser.

Yes, Heartbleed probably was a top-importance article when the news first broke and it might still be, but within a month it will probably drop to High-importance and within 6 months it will probably be at mid-importance or lower.

If anyone sees this message after June 1, 2014 please re-assess the importance. Ditto if anyone sees this message after about December 1, 2014. davidwr/(talk)/(contribs) 02:37, 26 April 2014 (UTC)

I don't know if Heartbleed will ever drop to mid-importance. The ramifications of Heartbleed aren't just limited to mitigating the impacts of the exploit itself. Heartbleed was sort of a wake up call that a lot of infrastructure may depend on inadequately supported projects. We'll have to see the long term implications of Heartbleed to know for sure whether it was just a temporary crisis quickly forgotten or a key turning point in internet security. – FenixFeather (talk)(Contribs) 03:26, 26 April 2014 (UTC)
I hadn't construed importance as something time-dependent before reading this, but I think it makes sense for Heartbleed. Current view statistics show this article as being as popular as Internet... and these statistics are much lower than the peak. I agree Heartbleed should hopefully drop to High at some point, and perhaps to Mid in the long term. I wouldn't set it lower though. I had previously reduced the Computing importance from Top to High. --Chealer (talk) 20:28, 26 April 2014 (UTC)

Misleading donation figures[edit]

A discussion at the end of the article summarizing Dan Kaminsky's opinion says,

After learning about donations to the OpenSSL project totaling $841, he commented "We are building the most important technologies for the global economy on shockingly underfunded infrastructure."[144] Other sources cite yearly donations of about US$ 2000.[145]

This is misleading. The Wall Street Journal article which Kaminsky cited says,

Last year, the foundation took in less than $1 million from donations and consulting contracts.
Donations have picked up since Monday, Mr. Marquess said. This week, it had raised $841.70 as of Wednesday afternoon.

I'm not disputing that OpenSSL has historically had a very small budget. But there's a big difference between "less than $1 million", "$2000", "$841", and "$841 in the last 3 days". The summary of Kaminsky's opinion should be revised to accurately reflect OpenSSL's actual budget and donations. --Bigpeteb (talk) 20:27, 28 April 2014 (UTC)

Resolved
Ah, that explains it. Kaminsky wasn't too clear and I must have missed his link. I misinterpreted Kaminsky big time and am very sorry about that. Thanks very much for reporting. I hope you'll find the new version OK. We still don't mention the "less than $1 million" since it's imprecise and includes more than donations, but it's at least mentioned on OpenSSL. --Chealer (talk) 20:15, 30 April 2014 (UTC)

Edit warring "request for reference"[edit]

Chealer now insists that the patently obvious statement that a custom memory allocator caused the problem is false, and did not in fact cause Heartbleed. But the source clearly says:

So years ago we added exploit mitigations counter measures to libc

malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it's own, and not free it to the protective malloc.

I am confused as to why he insists on edit warring over things like this, but this is a necessary step before reporting him for repeated edit warring in this article. Previously, he had done this with LastPass and also refused to participate in Dispute Resolution. I expect similar recalcitrance this time around. – FenixFeather (talk)(Contribs) 00:08, 30 April 2014 (UTC)

What you cite is from [13]. As I explained in User_talk:FenixFeather#Heartbleed_-_Custom_memory_management, we can't claim that a custom memory allocator caused the vulnerability just because it prevented OpenBSD's countermeasures. OpenBSD is just one OpenSSL platform among many. --Chealer (talk) 01:25, 30 April 2014 (UTC)
He is an OpenBSD developer, but he is not talking about OpenBSD in the email. He is specifically explaining why OpenSSL failed; it has NOTHING to do with OpenBSD, despite the similarity in name. Because reading comprehension seems to be problematic for you, I will provide the email here and highlight all the relevant words:

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc malloc and mmap, so that a variety of bugs can be exposed. Such memory accesses will cause an immediate crash, or even a core dump, then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so that the library will cache memory on it's own, and not free it to the protective malloc.

You can find the comment in their sources ...

  1. ifndef OPENSSL_NO_BUF_FREELISTS

/* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you build protective technology into malloc() and free(), it will be ineffective. On ALL PLATFORMS, because that option is the default, and Ted's tests show you can't turn it off because they haven't tested without it in ages.

So then a bug shows up which leaks the content of memory mishandled by that layer. If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Please just admit you are wrong and make constructive edits instead of tagging things and telling others to find ultraspecific sources only you demand. – FenixFeather (talk)(Contribs) 01:31, 30 April 2014 (UTC)
First of all, I am a very demanding person. I happen to have "adopted" this article a couple of weeks ago and to be its de facto "maintainer". Perhaps because of my perfectionism, the maintainers who I borrowed it from appear to have stopped watching it, which is unfortunate in a sense. This doesn't mean that nobody else cares about the article. In fact, it still has over 10 000 reads daily. I don't think what may be perceived as attention to detail is unwarranted. After all, Heartbleed has even affected this very website. That being said, let's try to focus on our content issue...
You may say Ted's mail isn't talking "about OpenBSD", but he's still talking in the context of OpenBSD. What Ted explains is not necessarily specific to OpenBSD. Some other operating systems share its security concerns and will also feature hardened memory management.
However, we would still be discussing Heartbleed had OpenSSL not used custom memory management. OpenBSD wouldn't, but we at Wikipedia and the world at large would still be discussing the bug and its impact on a lower number of systems. --Chealer (talk) 02:34, 30 April 2014 (UTC)
You don't own this article. In case you haven't read the sentence, I will post it again: "If the memoory had been properly returned via free, it would likely have been handed to munmap, and triggered a daemon crash instead of leaking your keys.". That is not in the context of OpenBSD. Just because he is the lead developer of OpenBSD does NOT mean his life and everything he says revolves around OpenBSD. If you are so interested in maintaining this article, go find real issues instead of quibbling over more requests for reference for obvious, common sense and stuff supported by reliable sources. By all means, if you are interested in finding another source, go right ahead. There is an excellent tutorial at WP:REFB, but there is no need to bother other editors about nitpicking for every small thing. – FenixFeather (talk)(Contribs) 02:38, 30 April 2014 (UTC)
Nobody fully owns this article (except for the sum of its authors, to be exact). Sorry to re-repeat myself, but I am not interested in sourcing that material per se. What I am interested in is to keep the article in compliance with our policies.
It is not the fact that the sentence was written by an OpenBSD developers which shows that it's in the context of OpenBSD. It is the fact that it was sent to an OpenBSD mailing list (misc@openbsd.org). Although it is not entirely OpenBSD-specific, as previously explained. --Chealer (talk) 03:10, 30 April 2014 (UTC)
All right then, glad you finally agree that the current source is sufficient. If you're interested in adding another source, go ahead and do a quick search and cite it. Trust me, it's not that hard to cite sources. Once again, I highly recommend WP:REFB. – FenixFeather (talk)(Contribs) 03:23, 30 April 2014 (UTC)
Uh... quoting myself:

I am not interested in sourcing that material per se. What I am interested in is to keep the article in compliance with our policies.

Nobody's ever denied that the current source was sufficient to support de Raadt's reproach to OpenSSL. The problem is just with the flagged sentence. --Chealer (talk) 03:46, 30 April 2014 (UTC)
Then I fail to see your problem. That source supports the entire passage, and I've explained countless times why it does. Can we just agree on that? If you want a better source, go find it. But cn is only for certain use scenarios. Note that the Wikipedia policy on cn says "If you have the time and ability to find an authoritative reference, please do so. Then add the citation yourself, or correct the article text. After all, the ultimate goal is not to merely identify problems, but to fix them. While an editor may add this template to any uncited passage for any reason, many editors object to what they perceive as overuse of this tag, particularly in what is known as "drive-by" tagging, which is applying the tag without attempting to address the issues at all (hit-and-run)." At this point, we can consider you to be guilty of drive-by tagging. I've seen you do this "request for reference" nonsense on the LastPass Heartbleed stuff, on this business, and on the LastPass article too. User:Tutelary was kind enough to find a source for you, but seriously, you need to stop. You've spent so much time arguing for the addition of a tag, that you could've spent that time finding the source you so dearly wanted. WP:FIXTHEPROBLEM instead of dragging people into this sort of thing every time you decide in your delusional alternate reality that a source does not support a claim here. – FenixFeather (talk)(Contribs) 03:59, 30 April 2014 (UTC)
Quoting myself:

The problem is, how do you "fix the problem" (pun intended)? There are 2 approaches to making articles verifiable - sourcing problematic content appropriately, or removing problematic content. Possibly out of respect for my colleagues, I prefer to give sourcing a chance rather than directly removing content (sometimes even when I'm confident that the content is unverifiable, indeed).

No, that source does not support the entire passage. I take orders from my employer and customers, not from strangers. Even if you offered the money, I guess I would lack "the time and ability to find an authoritative reference" which I'm confident doesn't exist. As I said, my LastPass-related edits show that giving sourcing a chance doesn't prevent me from removal when it becomes clear that content is unverifiable. I usually act the same regardless of the chances a given claim has to be verifiable, but if you prefer, you can read "challenge" instead of "request reference". --Chealer (talk) 06:12, 30 April 2014 (UTC)
Oh and by the way, since you've taken it upon yourself to be the primary maintainer of the article, that's even more reason why you should be hunting down those sources instead of tagging all over the place, especially when everybody else does not agree with your tags. – FenixFeather (talk)(Contribs) 04:07, 30 April 2014 (UTC)
I have not "taken it upon yourself to be the primary maintainer of the article". This happened gradually after I got involved. It was never my intention to drive previous maintainers away. I have no official commitment to this article and am not in any way more responsible than anyone else for its maintenance. I have no intention to spend time hunting down sources which I'm confident do not exist.
If you think everybody else disagrees with my tags and you still prefer discussing behavior to discussing content, feel free to show me examples of such contributors. --Chealer (talk) 05:57, 30 April 2014 (UTC)
That's too bad then, because the current source is quite good on the topic. The burden is on you to show a reliable source that indicates OpenSSL's custom memory function was not part of the problem (hint, it was, and everybody knows this). – FenixFeather (talk)(Contribs) 20:05, 30 April 2014 (UTC)
See WP:BURDEN on burden, but again, I'm not sure I would say that custom memory management was not part of the problem (it obviously at least worsened the issue). --Chealer (talk) 20:57, 30 April 2014 (UTC)
The burden has been satisfied. You are making a counterclaim that goes against what the current source says. Thus the burden is on you. – FenixFeather (talk)(Contribs) 21:02, 30 April 2014 (UTC)
If you think the current source supports the sentence, please quote where. --Chealer (talk) 21:31, 30 April 2014 (UTC)
Chealer, I'm not going to play this game with you. I've quoted nearly the entire article to you and pointed out where it supports the content. Go back and read it. Previously, with respect to certificate revocations discussion with User:A Quest For Knowledge, you've already demonstrated that you are not technically competent (or open minded enough to listen to those who are) enough to make these sort of judgments. If you want to be "de facto maintainer" of an article, go be the de facto maintainer of article you have expertise on. Not on an article where you purposefully choose not to understand obvious facts. – FenixFeather (talk)(Contribs) 22:02, 30 April 2014 (UTC)
You may very well have quoted the entire article, but you still haven't quoted a part which actually supports the problematic sentence anyway. As for my technical competence, you'll have to explain how I would have demonstrated such a thing. I am "de facto maintainer", I don't want to be, as I said. --Chealer (talk) 22:16, 30 April 2014 (UTC)
If you don't want to be, then stop being it. Nobody forced you to edit this article. Maybe in your imagination, you are "de facto maintainer". But in real life, editors are the maintainers of this article. If you had made valuable contributions to this article, I might agree with your evaluation of yourself as de facto maintainer. But as it stands, the only thing you have done is caused disruption and destruction through your drive by tagging, your edit warring, your "clarifications", your "reworks", and your removal of access dates. Please just let people who are more knowledgeable about the topic area handle these more technical parts, because I simply cannot explain to you any further without sounding like I am talking to a five year old. Read PaleAqua's explanation below if you need to. – FenixFeather (talk)(Contribs) 22:21, 30 April 2014 (UTC)
Not wanting to be and wanting not to be are 2 different things. I'll be happy to leave all parts of this article in better hands when these arrive.
It is highly ironic that your opinion concerns my contributions to this article. When I first saw the article, it was in such a bad state and I was so sick that I couldn't perform the changes required. But I started patrolling new edits anyway, and noticed edits implementing the first changes I intended to make. Since that happened in the 24 hours which followed my arrival, I was so impressed by ourselves that I considered blogging about LSSP's virtues. I was cooled off by an edit war happening at the same time and didn't blog in the end. Of course, that was before I started reviewing and - inevitably - being perceived more and more as the new bad guy... --Chealer (talk) 23:44, 30 April 2014 (UTC)
Nobody here is a bad guy. I'm simply frustrated that you choose to drag minor things like this on and on forever, and refuse to budge an inch on any issue to anyone else. Be more considerate of others and you'll be fine. I've seen you make productive edits before. – FenixFeather (talk)(Contribs) 05:17, 1 May 2014 (UTC)
I know there's no bad guy. The problem is perception.
If your problem is refusal to budge, I'll directly remove unverifiable content next time. Then merely flag it as unappropriate after you oppose. Then let you enjoy to see me compromising. Right? --Chealer (talk) 07:19, 1 May 2014 (UTC)
In reply to your insistence that he is only talking about OpenBSD because his email address says @openbsd, no he. Is. Not. He is talking about C code in general. C is a programming language that can be compiled for multiple platforms. In fact, if you read the man page, you can see he is right in that default malloc and free have built in memory safe guards. "Crashes in malloc(), calloc(), realloc(), or free() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing the same pointer twice.". So just stop with this nonsense. – FenixFeather (talk)(Contribs) 02:52, 30 April 2014 (UTC)
He may be talking about C code in general, but still in the context of OpenBSD (and other operating with hardened C standard libraries). Thanks for the link, but would you mind quoting the part supposed to show that "default malloc and free have built in memory safe guards"? --Chealer (talk) 03:37, 30 April 2014 (UTC)
I just did. "Crashes in malloc(), calloc(), realloc(), or free() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing the same pointer twice.". So if you use the normal C memory management functions, overflowing your allocated chunk of memory will crash. This is exactly what did not happen with Heartbleed. They accessed stuff outside their allocated memory, but instead of crashing, it responded with blocks of server memory. – FenixFeather (talk)(Contribs) 03:42, 30 April 2014 (UTC)
Hum, if that's the only material there, that manpage won't help much. What we can imply from that sentence is the obvious - some overflows will cause crashes. That's a long way from implying that a simple read of unallocated memory would necessarily crash.
Not that this is uninteresting, but if I may save you some efforts, you'll notice a sentence just after the problematic one: "In addition, by using its own memory management routines OpenSSL bypassed mitigation measures in some operating systems that might have detected or neutralized the bug." (emphasis mine). Unless you take issue with that part, that's a pretty clear suggestion that only some operating systems have such mitigation measures in place... --Chealer (talk) 05:42, 30 April 2014 (UTC)
Note it's not just operating systems that have this type of checking in place, or have the ability to initialize malloc memory and cause double frees to fail ( such as Linux's mallopt and stuff like M_PERTURB ) but it's also common various memory analysis tools such as Purify or Valgrind. Using these types of tools are fairly common during development but tend not to work against bugs in code with custom memory handlers. As OpenSSL is a library any developer using it with one of those tools would have likely seen the problems if a system malloc was used. Many development IDEs have these tools. PaleAqua (talk) 07:29, 30 April 2014 (UTC)
Although the deraadt reference does mention that, we have not covered it in the article yet. This could be covered in the analysis section, although it may be getting a little far for my taste. --Chealer (talk) 16:04, 30 April 2014 (UTC)
This is not about your "taste", this is about reality, that which is true whether you believe it or not. You need to stop hanging onto your delusional protests and start listening to other editors, instead of stubbornly clinging to your edits. – FenixFeather (talk)(Contribs) 16:12, 30 April 2014 (UTC)
The level of detail we want from our articles is relative. We can't say an article is "8/10" in completeness, and even if we could, some would promote a higher level than others. That's why I'm not saying the fact PaleAqua highlighted should not be covered. Let's say I'd recommend the short version if someone wants to write something. --Chealer (talk) 17:08, 30 April 2014 (UTC)
Unless I'm understanding them wrong, PaleAqua is not talking about facts we should include, but explaining to you how memory allocation works. Please just listen to others. You are in a one person minority that believes the custom memory function in OpenSSL was not part of the problem. It was. Please stop denying reality. – FenixFeather (talk)(Contribs) 20:09, 30 April 2014 (UTC)
Not really an explanation of how memory allocation works, but sorry if I got PaleAqua's intent wrong. I'm not sure I would say that custom memory function in OpenSSL was not part of the problem. Obviously, they at least worsened the issue. --Chealer (talk) 20:47, 30 April 2014 (UTC)
Then why is this such a big issue? That is exactly what the source and the content say. Can you just concede now, or do you have to keep beating the dead horse? – FenixFeather (talk)(Contribs) 20:59, 30 April 2014 (UTC)
"Such a big issue"? I merely requested to source the problematic sentence. What could I concede? --Chealer (talk) 21:31, 30 April 2014 (UTC)
Not exactly, what I was explaining was not how memory allocations work, but how the custom allocators compounded the issue on more than just OpenBSD or just some OSes. The custom allocators would prevent memory bugs from being visible during typical software development cycles. The bug would have still existed with or without the custom memory handlers. It's just likely that it would have been caught earlier and would have been more a denial of service attack instead of a security breach as the attempts to read outside memory would have triggered page faults on some servers. All of this seems pretty common sense to me ( but then again I am a software tools developer. ) PaleAqua (talk) 21:26, 30 April 2014 (UTC)
It is common sense to anyone who has a modicum of technical knowledge or has read the cited source, or even the Wikipedia article. Chealer, unfortunately, has repeatedly demonstrated that he will not listen to anyone else, no matter how common sense it is. – FenixFeather (talk)(Contribs) 22:00, 30 April 2014 (UTC)
Note that I never refused to participate in Dispute Resolution. --Chealer (talk) 03:10, 30 April 2014 (UTC)

@Chealer: You need to stop making edits without reading the sources. You just edited the LastPass entry to make it seem as if LastPass's password transmissions were vulnerable: "its usage with vulnerable websites may have compromised the passwords transmitted". They were not. LastPass passwords are encrypted before even being transmitted in the first place. LastPass told its users to change their passwords because OTHER servers could have been compromised, not because LastPass is vulnerable. Stop "clarifying" stuff. You have no idea what you're doing. – FenixFeather (talk)(Contribs) 16:09, 30 April 2014 (UTC)

LastPass's password transmissions were vulnerable in a sense, i.e. when using it with vulnerable websites, just like the transmissions of Firefox or any browser. LastPass passwords are not necessarily encrypted, but yes, they are encrypted in the cases concerning us (when using with TLS websites). This doesn't mean, of course, that they can't be decrypted when a cryptographic key is comprised. As for

LastPass told its users to change their passwords because OTHER servers could have been compromised, not because LastPass is vulnerable.

...that's why we explain that "LastPass itself is not vulnerable in practice". I'm sorry you don't see the new version as clearer. To be honest, the issue's complexity is part of why the first solution I chose was to remove our coverage entirely (I only went for a fix after someone re-added the item). --Chealer (talk) 17:08, 30 April 2014 (UTC)
Removing something because you don't understand it is not the right approach to the problem. Your wording made it more confusing when it was perfectly fine before. – FenixFeather (talk)(Contribs) 17:18, 30 April 2014 (UTC)
The issue's complexity doesn't simply make it harder to understand for us, it makes it harder for the reader (or, it makes it harder for us to explain it to the reader). I'm sorry you find the wording more confusing. If you find some part could cause confusion, feel free to explain how. --Chealer (talk) 19:24, 30 April 2014 (UTC)
I've already explained, but I have no interest in fighting more with you. I'm sure nobody else is as interested as you are in LastPass anyway. – FenixFeather (talk)(Contribs) 20:01, 30 April 2014 (UTC)

Footnotes and accessdates[edit]

Also, why are you removing access dates from citations? They're a valuable part of references. I just don't understand why you edit so disruptively like this. – FenixFeather (talk)(Contribs) 16:14, 30 April 2014 (UTC)

I'm only removing those which already have a date to size down the article a little. Access dates are unlikely to be used when we already have a publication date (see Template:Cite_web/doc#URL). In the unlikely event that one is needed to help verifying a source, they can be digged from history quite reliably. --Chealer (talk) 17:15, 30 April 2014 (UTC)
They are NOT REQUIRED, not that they should be removed. These pages are news sources that may change in the future, and not static. There is no need to remove access dates. I don't want to have to hunt down an edit in the edit history just to figure out when an article was accessed. Please stop disruptively editing. – FenixFeather (talk)(Contribs) 17:18, 30 April 2014 (UTC)
No. Wikitech-l is a mailing list. The reference to it is a mail, which will not change in the future. It is perfectly static. There is of course no need to remove superfluous access dates, just like there is no need to add access dates. Many things we do are not necessary neither. --Chealer (talk) 19:30, 30 April 2014 (UTC)
Let me remind you that one of the sources from which you removed the access date was a news article I cited to put a temporary stop to your edit warring. There is no excuse for removing access dates, especially in that scenario. Access dates don't hurt, and they are often a required standard for citing web materials in many citation style manuals. – FenixFeather (talk)(Contribs) 20:01, 30 April 2014 (UTC)
There's of course nothing wrong with access dates in general, but this is a wiki. The access date is the date of the edit which introduced the reference (with exceptions), so displaying it is quite redundant when we already display the publication date. There's no excuse needed to remove them in these cases. You can remind me that I removed an access date from a news article, and I can remind you that news articles rarely change. It's as unlikely that the article is changed as it's unlikely that someone ever needs to find the access date anyway.
If it wasn't for the fact that they enlarge the article further, I'd agree access dates don't hurt significantly. It would be nice to be able to hide those unlikely to be used. --Chealer (talk) 20:41, 30 April 2014 (UTC)
Are you kidding me? Web pages change all the time, which is why access dates are so important. News articles often change their text or add corrections. I can't remember how many times I've come across a dead link in a ref, and have had to find a webarchive link for it. Having the access date conveniently there is crucial to locating a good date for the webarchive wayback machine, especially to verify the information. Stop being stubborn and accept that sometimes you can make mistakes. – FenixFeather (talk)(Contribs) 20:54, 30 April 2014 (UTC)
A dead link simply prevents you from accessing the last version. If you want the last version, you just take that from the wayback machine. --Chealer (talk) 21:00, 30 April 2014 (UTC)
Jesus. I don't know how you can be so ignorant on this sort of thing, but for verifiability, it is important that we use the version the original author used. That's why access date is so critical for web sources, because of how unstable they are. "Access dates bloat the article" is such an absurd argument. Just listen to yourself. Think before you speak. – FenixFeather (talk)(Contribs) 21:04, 30 April 2014 (UTC)
The current version is equally verifiable in the vast majority of cases, in particular when we have a publication date. I can live with the idea that I may have caused someone to lose a few minutes digging the history, as they'd probably have done anyway to see who added the reference. But thanks for your opinion. I wasn't aware that some people were that attached to all access dates. --Chealer (talk) 21:25, 30 April 2014 (UTC)
There is zero harm in access dates. There is potential harm in removing them. End. Of. Story. – FenixFeather (talk)(Contribs) 21:30, 30 April 2014 (UTC)
Any content is "harmful", in the sense that it has a cost. The perfect article could be entirely read in 0 seconds. Unfortunately, that article would be of little use. We are in a world of trade-offs, even though that can be difficult to accept. We also have to accept and deal with the conflicts caused by diverging opinions on where to draw the lines. --Chealer (talk) 21:39, 30 April 2014 (UTC)
@Chealer: You shouldn't be removing access dates. If you do, you need to take the time to re-add them. A Quest For Knowledge (talk) 21:40, 30 April 2014 (UTC)
The time it would take to re-add would be out of proportions and I don't intend to do that. However, I did assume that removing superfluous dates was uncontroversial, and am sorry for that. Thanks for sharing your opinion. --Chealer (talk) 21:50, 30 April 2014 (UTC)
Chealer, this comment is demonstrative of your attitude towards editing on Wikipedia. You are not interested toward editing constructively. You are not interested in listening to others. You tag obvious facts, you "clarify" things in a way to make them more confusing, you remove, of all things, access dates. Go out, do research, find something valuable, and add to the article, instead of power tripping as the pretend "de facto maintainer" of the article. You say you have no time for re-adding access dates, but apparently other people have time for digging through edit history to find access dates? Wait, you just said it wouldn't take much time. Stop being self centered. Get off your butt and go do real work, stop sitting around and disrupting others' work when you're not willing to put in the effort yourself. – FenixFeather (talk)(Contribs) 21:57, 30 April 2014 (UTC)
It's one thing to dig one access date. It's a different thing to dig up to 149 access dates, many of which won't come up, without any help from edit summaries, unfortunately. --Chealer (talk) 22:06, 30 April 2014 (UTC)
We never said you had to dig up 149 access dates, just that you should restore the ones that you have removed, if you have removed any. If you have removed 149 access dates, then yes, you need to go dig them up and restore them. It is not other people's responsibility to compensate for your wanton destruction. – FenixFeather (talk)(Contribs) 22:10, 30 April 2014 (UTC)
Fair enough, but since I made even more edits on this article, that would take quite a while too. --Chealer (talk) 22:26, 30 April 2014 (UTC)
That's fine, as long as you track down every single one you deleted. There is no deadline, so take your time with restoring them. It might give you something to do other than tagging random stuff. – FenixFeather (talk)(Contribs) 22:28, 30 April 2014 (UTC)
Unfortunately, I don't think I'm immortal, so there is a deadline. Thanks for the suggestion, but rest assured I don't need more things to do. --Chealer (talk) 23:23, 30 April 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── You removed that many access dates that it would take an entire lifetime to restore them all? My god, I don't know whether to be impressed or horrified. If you did cause such massive disruption, I suggest you do not continue to do so in the future. We can't force you to fix your past mistakes, but keep in mind that every mistake of yours you do not fix, you are imposing on other people's time. Other people are mortal too. Don't be selfish. – FenixFeather (talk)(Contribs) 23:28, 30 April 2014 (UTC)

No. I simply happen to have other things to do in my life than to restore access dates in references which already have a publication date. --Chealer (talk) 23:51, 30 April 2014 (UTC)

Oh and if you don't need more things to do, if you would kindly resign your position as "de facto maintainer" and un"adopt" this article, that would be great. Alternatively, you could just decide to be cooperative and not drive by tag, delete sections for being too confusing to you, remove access dates, "clarify" things without looking at sources, etc. Put some effort into it. – FenixFeather (talk)(Contribs) 23:31, 30 April 2014 (UTC)

One can't resign from a de facto position. What I can do is to welcome other people to make my involvement here unneeded. And I am hereby doing that with great joy. --Chealer (talk) 23:51, 30 April 2014 (UTC)
Any content is "harmful", in the sense that it has a cost. The perfect article could be entirely read in 0 seconds. Unfortunately, that article would be of little use. We are in a world of trade-offs, even though that can be difficult to accept. We also have to accept and deal with the conflicts caused by diverging opinions on where to draw the lines. --Chealer (talk) 21:39, 30 April 2014 (UTC)
I'd just like to note, there is no reason for one editor to be overriding the entire article. Content decisions are based on WP:CONSENSUS, whether we like it or not. I personally feel there is a value in the accessdate as it tells us when the article was last 'touched' by a user, and is convenient to the formation and people looking at the sources. I opt to include. Tutelary (talk) 21:43, 30 April 2014 (UTC)

Wikipedia guidelines specifically say accessdates should be included. See the 2nd paragraph of Wikipedia:CITE#Links and ID numbers. PaleAqua (talk) 22:13, 30 April 2014 (UTC)

What we're supposed to be discussing here is only references which have a publication date set. --Chealer (talk) 22:26, 30 April 2014 (UTC)

Editing Wikipedia is a collaborative effort[edit]

@Chealer: Editing Wikipedia is a collaborative effort that requires editors work in an atmosphere of camaraderie and mutual respect. If you or anyone thinks that their edits edits are more important than other editors', then they are mistaken. Please take the time to understand the concerns of others who have just as much right to edit this article as you do. A Quest For Knowledge (talk) 22:17, 30 April 2014 (UTC)

Does OpenSSL's custom memory management increase the likelihood of sensitive leaks?[edit]

In this diff [14] I added the sentences "As a result, the oversized memory buffer returned to the requestor was likely to contain data from memory blocks that had been previously requested and freed by SSL. Such memory blocks may contain sensitive data sent by users or even the private keys used by OpenSSL." User:Chealer and I have been having a polite chat about this on my talk page, and I think the discussion needs to be brought here. I based the sentences on my reading of the references cited above, but at Chealer's prodding I took a look at the OpenSSL source code (e.g. [15] Line 599 ff] and the situation is a bit more complicated. It seems that OpenSSL maintains its own lists of freed memory chunks. When it needs memory it first tries to get a previously freed chunk off the free_list. If it can't, it requests memory in standardized chunks via the operating system's malloc. When OpenSSL is done with a memory chunk, it tries to place it back on the free_list, which has a count of how many free blocks are on it. There is a maximum value for the number of blocks on the free_list and if the fee_list is full, the memory chunk is instead returned by the OS free() library function. I think what I wrote is still true in this model, as many chunks will be allocated quickly at startup and will likely be near each other, but this is clearly OR on my part and tentative at that (OpenSSL is notoriously hard to read). I notice that the sentences in question were recently removed. I will continue to look for a reliable source for them, and welcome help in the search, but until a reliable source is found, I suggest they should not be restored.--agr (talk) 21:41, 7 May 2014 (UTC)

PaleAqua made an edit regarding free lists a couple weeks ago. I think they came to some conclusion regarding them. – FenixFeather (talk)(Contribs) 00:30, 8 May 2014 (UTC)
I looked at the same code and originally reached a similar conclusion, but it seems that the heartbeat code using the OPENSSL_malloc wrappers directly instead of going through the free list first. So while the first list might make OpenSSL more vulernable in general I no longer think it applies to the heartbleed issue. Another thing to note is that there are actually several free lists ( two per context, one for reading and one for writing ) and the size of the blocks on the free list are fixed as soon as atleast one block is added, so it doesn't seem to have the all same flaws that a general free-list implementation would. See also my talk where Chealer questioned me on it which lead me to revert my changes. I also agree that a lot of this is OR. What it seems like to me is that OpenSSL has been critized not just for issues related to heartbleed, but other possible issues not involved in the heartbleed issue. We need to be careful to be clear on the distinction and not imply that all OpenSSL concerns are part of heartbleed. PaleAqua (talk) 01:21, 8 May 2014 (UTC)
I haven't found any support for de Raadt's assertions about OpenSSL memory management playing a role, so I took out the remaining sentence about memory management from the Behavior section. We still have de Raadt's comments in the Root causes, possible lessons, and reactions section, but I'm wondering if that should go as well, or be balanced in some way.--agr (talk) 20:14, 9 May 2014 (UTC)
I'm not sure what balancing could be done, but Wheeler's How to Prevent the next Heartbleed is very clear on the memory allocator's importance. I'd strongly oppose to complete removal. --Chealer (talk) 22:06, 9 May 2014 (UTC)
Wheeler's main point is that a properly instrumented memory allocator can help prevent bugs like Heartbleed. But he also repeats the claim that Heartbleed's use of a free list contributed to Heartbleed. Apparently it did not, and I don't think we should do any more to perpetuate this story. Balance would be to find a source that says it isn't true. Absent that, we could explain Wheeler's advice on using allocators, while not repeating the apparently untrue claim.--agr (talk) 03:01, 11 May 2014 (UTC)

The article misses some important big picture aspects[edit]

Unfortunately, this article (like much of the information currently available online as of 5/8/14) misses some very important aspects of the HeartBleed bug. Among them:

  • While O/S are generally immune, application software packages often embed a copy of OpenSSL which itself can be vulnerable. This is true on every popular platform, and is a vendor-recommended action.
  • Some vendors continue to offer vulnerable software on their App download sites, and little or no help to users who want to find and remediate vulnerabilities.
  • As a result of the above, the industry/community is now in a situation where most people have "moved on" yet HeartBleed is still a potentially large risk.

I will begin the process of adding extra information (yes with references) to the article, to ameliorate this. Mr Pete (talk) 19:58, 8 May 2014 (UTC)

I suspect the difficulty will be to find reliable information. Claw of Slime has kindly provided one such statistic.--Chealer (talk) 21:58, 9 May 2014 (UTC)

Apple's "recommendation to embed OpenSSL"[edit]

I'm removing the following sentence from the lead:

Apple recommends embedding OpenSSL in client applications when necessary for compatibility; as a result, Apple's FileMaker software required a fix.

Although FileMaker did require a fix as mentioned in the Impact section, the relation doesn't warrant treatment in the lead in my opinion and the sentence could be misunderstood. The need to fix FileMaker itself is in fact the result of a combination of circumstances:

  1. FileMaker using OpenSSL
  2. FileMaker linking OpenSSL statically
  3. The OpenSSL version embedded in some FileMaker versions being vulnerable

At most, Apple's recommendation could have been a factor in 2. --Chealer (talk) 19:55, 10 May 2014 (UTC)

Note that Apple actually recommends against using OpenSSL all together, and only recommends embedding only when OpenSSL is used to maintain source compatibility. On the other hand FileMaker is a subsidiary of Apple. PaleAqua (talk) 20:16, 10 May 2014 (UTC)

Undid massive, undiscussed changes.[edit]

I'm sorry I had to do this, but I've undone massive undiscussed changes[https://en.wikipedia.org/w/index.php?title=Heartbleed&diff=608181479&oldid=608069774 which unfortunately, did not improve the article. Chealer, please begin discussion on the talk page before making such sweeping undiscussed changes. Thanks. A Quest For Knowledge (talk) 09:36, 12 May 2014 (UTC)

Unfortunately, one of the inaccurate changes has been restored to the article (without engaging discussion) so again, I've made the article more accurate. Again, the Heartbleed bug has not be resolved. Thousands of web servers and millions of Android phones remain vulnerable. A Quest For Knowledge (talk) 23:53, 22 May 2014 (UTC)
Which inaccurate change? --Chealer (talk) 03:06, 25 May 2014 (UTC)
As I just said, "the Heartbleed bug has not be resolved. Thousands of web servers and millions of Android phones remain vulnerable." A Quest For Knowledge (talk) 10:45, 27 May 2014 (UTC)
There is some truth in that, but that doesn't say which inaccurate change you were referring to. --Chealer (talk) 14:48, 28 May 2014 (UTC)
Are you serious? I've told you repeatedly what the inaccurate change was: the part that says that issue has been resolved. Let me repeat myself in no uncertain terms: It. Has. Not. Been. Resolved. Please stop changing the article to say that the issue has been resolved when it hasn't. As eWeek reported, Heartbleed will be a problem for months, if not years to come.[16] In any case, I've reverted the misleading information.[17]] Please stop edit warring to include this change. Instead, please seek consensus on the talk page before doing this again. A Quest For Knowledge (talk) 23:36, 10 June 2014 (UTC)
I am extremely serious. A part is not a change. --Chealer (talk) 16:40, 11 June 2014 (UTC)
Huh? What does that even mean? Changing part of an article is not changing an article? You're not making any sense. A Quest For Knowledge (talk) 05:07, 12 June 2014 (UTC)
Changing part of an article implies changing an article. What I meant is that you're not making sense when you claim that a part of an article was the change you consider inaccurate. A part of an article does not constitute a change. --Chealer (talk) 17:21, 15 June 2014 (UTC)
Yeah, the Heartbleed issue by far isn't resolved. OpenSSL, as a library, was patched, but there are still millions of various devices that are left with vulnerable versions of OpenSSL. Who knows when those will be patched, and probably a large portion of them will remain vulnerable forever – just think of older Android devices receiving no more any software updates from their manufacturers. — Dsimic (talk | contribs) 03:56, 15 June 2014 (UTC)
I agree. Given the technical nature of this topic, I think it would be best if any changes that significantly alter the meaning of the article should be proposed and discussed on the talk page first to avoid unnecessary reverting. – FenixFeather (talk)(Contribs) 06:44, 24 May 2014 (UTC)
Regrettably, Chealer has once again edit-warred his preferred version into this article against this talk page discussion.[18] Chealer, so far, nobody agrees with you and everyone who's expressed an opinion has disagreed with you. Please stop trying to force your changes thru edit-warring. Instead, seek consensus first. If you fail to gain consensus, then you need to accept that nobody agrees with you and you need to let it go. A Quest For Knowledge (talk) 01:44, 20 July 2014 (UTC)
Ahem. If that's what you call massive changes, you must be using a massively different sense of "massive" then those I'm used to, which I encourage you to teach to our article first. --Chealer (talk) 20:30, 9 August 2014 (UTC)
So far, nobody is agreeing with you. If you continue to edit-war against talk page consensus, you risk being sanctioned. Please stop. A Quest For Knowledge (talk) 23:39, 21 August 2014 (UTC)
If there had been a consensus on this issue, I wouldn't have had to revert your change. --Chealer (talk) 22:29, 1 September 2014 (UTC)
That argument works both ways. The correct solution is not a slow edit war, but discussion. I actually find "code patch" to be a bit too weak as it implies that a quick fix patch was made and not that the library was fixed, while "resolution" implies that the vulnerable machines have all been fixed. How about something like "OpenSSL fix release" or "Fix release and deployment"? PaleAqua (talk) 05:30, 2 September 2014 (UTC)
@PaleAqua: I agree that a slow edit war is not the answer and I've tried to engage Cheeler on the talk page but as you can see, they post nonsensical or nonresponsive posts such as "A part is not a change". As I pointed out in May, Heartbleed has not been resolved; it continues to affect millions of computing devices. The very recent hack of millions of medical records demonstrates that Heartbleed still has not be resolved. As of yet, Cheeler hasn't even responded to this issue. They keep reverting but won't explain why. In any case, I would welcome alternate opinions or perhaps taking this to the WP:DRN, but it's been extremely frustrating when they continually revert you without any meaningful engagement on the talkpage. Also pinging @Dsimic: and @FenixFeather:. A Quest For Knowledge (talk) 22:36, 2 September 2014 (UTC)
@Chealer and A Quest For Knowledge: While I haven't been heavily involved in this page ever since the little kerfuffle a few months back, I have to agree with A Quest For Knowledge on this issue. Because of the technical nature of this page, we really should discuss anything remotely controversial on this page before unilaterally making edits. Let's try to avoid having to take this to the admin noticeboard again. Are there any specific conflicts that we could provide some input on? – FenixFeather (talk)(Contribs) 01:23, 3 September 2014 (UTC)
@PaleAqua: I do not see how "Resolution" would imply that the vulnerable machines have all been fixed. It merely implies the section is about the issue's resolution. --Chealer (talk) 01:36, 3 September 2014 (UTC)
This is where everyone else doesn't agree with your interpretation. The "issue" is not that there was a bug, it's that there was a bug that allowed security breaches. Calling the bug fix a "resolution" ignores the true impact of the Heartbleed bug. That issue will not be "resolved" until all affected sites are patched, certificates are revoked, passwords are changed, etc. By talking about the bug fix and calling it a "resolution", it makes it sound to the reader like the bug fix is all that's needed. Since this isn't the case, it's inaccurate to call the bug fix a "resolution". --Bigpeteb (talk) 14:01, 3 September 2014 (UTC)
This is equally true for any bug which has been deployed. Fixing it does not immediately stop its consequences. You may argue that "fixing" a bug does not resolve it, but that's still what we say. --Chealer (talk) 01:25, 6 September 2014 (UTC)
To me, too, naming that section "Resolution" is somewhat misleading, as the whole problem is how widespread the bug still is, and who knows for low long it's going to stay around. The bug has been resolved as a software bug, but the whole Heartbleed vulnerability is far away from becoming resolved and that's why "Resolution" isn't the best section title. "Code patch" also isn't the best possible section title, but at least it isn't misleading; how about using "Bugfix and its deployment" instead, or maybe simply "Bugfix" or "Fixed version"? — Dsimic (talk | contribs) 19:23, 3 September 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Responding to the ping, others have already given good reasons on why "Resolution" is a bad section heading, which I agree with. The bug might be fixed the the issue at many many sites is far from resolved. As to Dsimic's suggestion: "Bugfix and its deployment" etc sound good. Though both those and my earlier suggestions seem slightly awkward to me. How about "Progress of fix deployment" or "Fix deployment progress"? Ideal header should get across that there is a fix, it is being deployed, but that many sites have not yet had the fix deployed. PaleAqua (talk) 21:54, 3 September 2014 (UTC)

I agree that pretty much all suggestions we've come up with so far (including mine, of course) are slightly awkward. Hm, how about "Bugfix development", "Fixed version deployment", or "Fixed version and its deployment" – or maybe even "Resolution progress", which would also be some kind of a compromise? — Dsimic (talk | contribs) 22:44, 3 September 2014 (UTC)
Out of the suggestions given so far, I like "Bug fix" the best. "Code fix" would also work for me. Appending "and deployment" is also fine. A Quest For Knowledge (talk) 02:33, 4 September 2014 (UTC)
Sounds good. So then shall we go with "Bug fix and deployment" "Bugfix and deployment"? Which would eventually allow deployment to be split into it's own section leaving just "Bug fix" "Bugfix" PaleAqua (talk) 03:59, 4 September 2014 (UTC) (Changed bug fix => bugfix per Dsimic below PaleAqua (talk) 12:28, 4 September 2014 (UTC))
👍 Like, however to me "bugfix" is more of a single word. — Dsimic (talk | contribs) 05:24, 4 September 2014 (UTC)
How about something that highlights the important issue: "bug fix has not been universally (or widely) deployed". Glrx (talk) 00:38, 6 September 2014 (UTC)
In the spirit of compromise, I've gone ahead and implemented PaleAqua's suggestion. Hopefully, this resolves the matter. A Quest For Knowledge (talk) 23:53, 7 September 2014 (UTC)
FWIW, "Bugfix and deployment" is fine with me. — Dsimic (talk | contribs) 23:58, 7 September 2014 (UTC)
Splitting (or creating subsections) is certainly worthy of consideration, and "Bug fix" and "Deployment" would be good titles. --Chealer (talk) 01:25, 6 September 2014 (UTC)
"Bugfix development" is better than "Patch", but like "Fixed version deployment", it only captures part of the topic. "Resolution progress" is probably the suggestion I dislike the least. Similarly, "Progressive resolution" or "Gradual resolution" are possible. --Chealer (talk) 01:25, 6 September 2014 (UTC)

I recommend avoiding "Fixed version". I'd expect a section with such a title to say nothing more than "The bug was fixed in 1.0.1." --Chealer (talk) 01:25, 6 September 2014 (UTC)

Infographic in Impact[edit]

In the impact section I feel like File:StickyPassword Heartbleed Infographic.png would be a good display of community effort to educate and help users understand what Heartbleed is about. However the nature of it been very vertical makes the thumbnail pretty ugly and an eyesore. What can we do about that? —f3ndot (TALK) (EMAIL) (PGP) 20:39, 2 June 2014 (UTC)

I personally wouldn't support that infographic in the article. It's certainly useful and explains the situation, but in addition to being hard to place into the article, it doesn't add anything more than what is already said in the prose, and is ultimately promotional of password managers (seeing that the infographic is made by StickyPassword, and the infographic suggests the use of StickyPassword and/or other password managers at the bottom). ~SuperHamster Talk Contribs 22:12, 2 June 2014 (UTC)
I would strongly disagree with inclusion of that infographic, even if its form was optimal. I previously removed "coverage" of that infographic, mostly for other reasons. But I agree with SuperHamster - if there's any new information there, it should be integrated in text, and that infographic is mostly promotional. It offers unnecessary advice (each of the 4 advices). The average person wants to change a password only if the website advises them to do so. You might want to stop using a service if its administrators don't react properly to Heartbleed and other threats, but that's not a call our average audience is in position to make. If one ends up changing many passwords, that might be a good occasion to start using a password manager, but Heartbleed isn't a big reason to do that. I have countless accounts and didn't change a single one. I don't consider myself that daring. Besides, at this point nobody is looking for that kind of advice anyway. I even consider the infographic misleading. --Chealer (talk) 03:33, 3 June 2014 (UTC)

GA Review[edit]

This review is transcluded from Talk:Heartbleed/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: 3family6 (talk · contribs) 15:46, 3 November 2014 (UTC)


GA review (see here for what the criteria are, and here for what they are not)
  1. It is reasonably well written.
    a (prose, no copyvios, spelling and grammar): b (MoS for lead, layout, word choice, fiction, and lists):
    No apparent copyvios, and the prose for the most part is acceptable. Layout and MOS standards are satisfactory. I have some comments, though:
  • "It was reported by a professor at University of Michigan that a computer in China that had been used for hacking and other malicious activities attempted on April 8, 2014 to exploit Heartbleed to attack a university server, which was actually a honeypot intentionally left vulnerable, designed to attract attacks which could then be studied.[50]" - This sentence is a disaster. I'd suggest rewriting as something like: "On April 15, 2014, J. Alex Halderman, a professor at University of Michigan, reported that his honeypot server, an intentional vulnerability designed to attract attacks in order to study them, had received numerous attacks originating from China. Halderman concluded that because his honeypot was a fairly obscure server, these attacks were probably sweeping attacks on large swaths of the Internet."
  • Jumping off from that, the whole history section should be cleaned up. It's not that the information isn't good, it's actually quite informative. But right now it's little clusters of small paragraphs. The examples should be elaborated upon and better integrated into the overall flow of the section.--¿3family6 contribs 03:21, 10 November 2014 (UTC)
  1. It is factually accurate and verifiable.
    a (reference section): b (citations to reliable sources): c (OR):
    This article is very well referenced, but the reference style needs to be consistent. Right now there are some references that are merely a title that links to the source, and the source date, while other references that also provide the publishing website, and yet other provide not only the publishing website, but the company supporting that website. My point is, the references need to follow a consistent standard.--¿3family6 contribs 03:21, 10 November 2014 (UTC)
  2. It is broad in its coverage.
    a (major aspects): b (focused):
    Scope, focus, and focus all check out.--¿3family6 contribs 03:21, 10 November 2014 (UTC)
  3. It follows the neutral point of view policy.
    Fair representation without bias:
    Article looks neutral to me.--¿3family6 contribs 03:21, 10 November 2014 (UTC)
  4. It is stable.
    No edit wars, etc.:
    There have been some disputes in the past, but whatever the problem was seems to have worked itself out, as the article has been stable for over a month apart from a single instance of vandalism.--¿3family6 contribs 16:03, 7 November 2014 (UTC)
  5. It is illustrated by images and other media, where possible and appropriate.
    a (images are tagged and non-free content have fair use rationales): b (appropriate use with suitable captions):
    Images check out. All free, with correct licensing info.--¿3family6 contribs 16:03, 7 November 2014 (UTC)
  6. Overall: Almost there, just needs some polishing up in the prose.
Green tickY All issues resolved.--¿3family6 contribs 20:22, 25 November 2014 (UTC)
  1. Pass/Fail: {{GAList/check|pass}
How's your progress, AmritasyaPutra? The changes you made certainly improved the article, but they aren't complete yet.--¿3family6 contribs 15:25, 14 November 2014 (UTC)
Yes, I will continue with the change, have been busy with my studies lately. I will need a few more days (lets say five). Thank you! --AmritasyaPutraT 14:08, 16 November 2014 (UTC)
That's acceptable. I completely understand. I don't mind this taking a while if you actually are trying to work on it.--¿3family6 contribs 18:11, 16 November 2014 (UTC)
I think the last edits by AmritasyaPutra took out too much content for no reason and in some cases oversimplified so that some of the remaining content did not make sense. For example "Possible prior knowledge and exploitation" is far less clear than "Possible knowledge and exploitation prior to disclosure"; the words "as part of a stockpile" makes the purpose of the alleged NSA withholding clear; and the "only 43%" and "In addition, 7%" wording indicate why these percentages are important. Tiptoethrutheminefield (talk) 21:01, 19 November 2014 (UTC)
However, I wonder about the "naming of names" in the history section. This risks giving undue weight (and undue blame). Though there is some content to give balance and context in the Root causes, possible lessons, and reactions section that indicates how much work on the coding was underpaid or unpaid and how impossibly small the development team was to oversee so much code. Tiptoethrutheminefield (talk) 21:17, 19 November 2014 (UTC)
Tiptoethrutheminefield, what do you mean by "naming of names?" Could you provide specific examples of what you see a problem with? AmritasyaPutra, I agree with Tiptoe that your edits, though they cleaned things up, destroyed some of the context. My problem with the history section wasn't so much the detail, but that the detail wasn't explained. It needs more context, not less.--¿3family6 contribs 02:16, 20 November 2014 (UTC)
The History section content names two people, Robin Seggelmann and Stephen N. Henson, saying essentially that they were to blame for the flaw existing - the first for creating it, the second for not noticing it: "Henson failed to notice a bug in Seggelmann's implementation, and introduced the flawed code...". While this seems correct, it is said without any wider context (for example, sources explain that OpenSSL development is mostly unfinanced, with no budget for proper code checking, yet users still expect something for nothing and expect it to be perfect and set up critical systems with the unjustified assumption that it IS perfect). There is something about that in that later section I mentioned, but that section is far away from the section that names those two individuals. Tiptoethrutheminefield (talk) 02:52, 20 November 2014 (UTC)
Well, it shouldn't be that hard to add some context to that section that discusses this.--¿3family6 contribs 05:03, 20 November 2014 (UTC)
I understand your concern, but unlike 3family6, I'm not sure how this could be significantly improved without important duplication. It is important to name names, not just for imputability (they did a big mistake), but to let readers take a lesson on the importance of code review (among other things). This wasn't Joe Blow committing his quick hack to OpenSSL. It was 2 highly-educated security experts - including one core OpenSSL developer holding a Ph.D. Yet, they both failed to avoid/notice the error, and both felt confident enough to proceed.
Our treatment is not only correct - indeed - but it does not "explicitly blame" anyone, it clearly shows that the responsibility is shared, and it does not suggest that the bug was introduced intentionally. That being said, I think they both did a honest error. I agree that the "Root causes, possible lessons, and reactions" section helps, and it's unhelpful that it is found at the other end of the article. Unfortunately, History is typically the first section, and the root causes section is quite rightly at the end (if sections are to be ordered by importance). I don't see a good restructuring which would help. Perhaps we could make the Appearance subsection link to the "Root causes, possible lessons, and reactions" section?? I don't remember seeing this kind of link elsewhere. --Chealer (talk) 05:03, 21 November 2014 (UTC)
I am the article's top contributor. This article is coming from very far, but it has made a very long way since I discovered it, thanks to the work of myself and many others. I personally invested many tens of hours in it, mostly to improve quality. I reviewed pretty much all of it. Reliability should be pretty high. I've already seen this GA process fix some of the more minor issues which had had less attention, like references. I am not knowledgeable about quality ratings, but I tend to agree that B may understate this article's quality.
I do not see much improvement possible in the History section. Some improvement can surely be made (perhaps adding new information), but this is one area which already received a lot of attention. --Chealer (talk) 04:04, 21 November 2014 (UTC)
This section is mostly okay now. The "Exploitation" section just needs to see the one-paragraph sentences merged together.--¿3family6 contribs 04:19, 21 November 2014 (UTC)
I agree the Exploitation section isn't impressive, in particular the crude "Anti-malware researchers exploited Heartbleed to access secret forums used by cybercriminals." There is some value in separating the elements covered by each paragraph, but it seems it is not enough to warrant different paragraphs. Unfortunately I do not see a good alternative. A list seems inappropriate, and a table would be complicated since we do not have a real date for some elements. --Chealer (talk) 04:43, 22 November 2014 (UTC)
I disagree with the removal of the date of Google's notice from the History section in revision 633247602. The time taken by OpenSSL to release a fix is very important, and since Google's notice was the first, I find its date most relevant. If the reason was the reference used, I agree a better reference than Google+ would be nice, but if we don't have one, I don't think that justifies removal. --Chealer (talk) 04:04, 21 November 2014 (UTC)
Yes, that information should be restored.--¿3family6 contribs 04:19, 21 November 2014 (UTC)
I restored the paragraph. --Chealer (talk) 22:18, 22 November 2014 (UTC)

Status?[edit]

AmritasyaPutra, it's been well over five days. Tiptoethrutheminefield and Chealer have pitched in here as well, but some of my concerns have still not been resolved satisfactorily. Right now, the "Exploitation" section needs a bit of polishing, and the reference list needs to maintain a consistent format. I understand about the pressures of keeping up with one's studies, plus participating in the GA cup, but there hasn't been much activity on this page. I'll leave this nom open for another few days, after which I will have to fail it.--¿3family6 contribs 21:16, 24 November 2014 (UTC)

I made few minor changes to the Exploitation section, another editor also pitched in and preferred to keep the smaller paragraphs separate owing to separate events. I have added author detail and accessdate to references and replaced all bare references to cite web format with details. I hope that helps. I will wait for your feedback. Thank you. --AmritasyaPutraT 15:37, 25 November 2014 (UTC)
The sources look much better, thank you. I reverted the edits by that editor, as myself, as the GA reviewer, insisted that the paragraphs be merged. The passages all are commonly linked by anti-malware/security research. All that remains for correction are these two phrases in "Exploitation:"
  • "Anti-malware researchers also exploited Heartbleed to their advantage by exploiting it to access secret forums used by cybercriminals." - repetitive use of "exploited"
  • "On August 2014, it was made public that Community Health Systems, a provider of general hospital healthcare services in the United States, had been breached by exploiting Heartbleed, compromising the confidentiality of 4.5 million patient records." - shouldn't this read "had been breached through an exploitation by Heartbleed?"--¿3family6 contribs 17:37, 25 November 2014 (UTC)
@3family6: thanks for that, I have reworded the statements to get rid of over-use of 'exploit' and circumvent use of 'breach' altogether. --AmritasyaPutraT 18:16, 25 November 2014 (UTC)
Looks good, everything is all set now.--¿3family6 contribs 20:22, 25 November 2014 (UTC)

Not affected[edit]

I thought the following sentence would be sufficient:

TLS implementations other than OpenSSL were not affected

so I removed the partial list of "not affected" implementations. Another editor restored it. I posted a question on his user page asking his reasoning. For example, you wouldn't make a list of people not running for President. It would never be complete, and it is pointless anyhow. Receiving no response from that editor, I now submit this question to fellow editors. Why list what's not affected? Or should that portion be removed? 129.219.155.89 (talk) 21:58, 4 November 2015 (UTC)

The lengthier passage had a citation. The shortened version needs a citation. Peaceray (talk) 20:42, 17 November 2015 (UTC)

bug fixation[edit]

in copied here section exist somehow problematic content. One problem is: the date 3/21 already put question to 4/1 date.

Bugfix and deployment

Bodo Moeller and Adam Langley of Google prepared the fix for Heartbleed. The resulting patch was added to Red Hat's issue tracke on March 21, 2014.<X1ref>"heartbeat_fix". Retrieved April 14, 2014. </ref> Stephen N. Henson applied the fix to OpenSSL's version control system on 7 April.<X2ref name="fix"/> The first fixed version, 1.0.1g, was released on the same day. As of June 21, 2014, 309,197 public web servers remained vulnerable.<X3ref>Graham, Robert (2014-06-21). [X4http://blog.erratasec.com/2014/06/300k-vulnerable-to-heartbleed-two.html#.U6bXBWSSwyC "300k servers vulnerable to Heartbleed two months later"]. Errata Security. Retrieved 2014-06-22. </ref>

  • the other problem is a numerical issue whit X1 :cgi?id=883475 dated 03-21
  • the cgi cgi?id=883472 have content: ...Saved core dump of.. and is dated 2014-04-06-19:23:14-3737

The probability of ~1/0.5M had to be lower by 1.2M (to 0.6T) since the other cgi?id= are not jumping in time. Can one look at the gov|corp side to put some explanatory dis. traction? 2601:248:4301:5A70:4A5D:60FF:FE32:8309 (talk) 03:15, 21 August 2016 (UTC) 5/\