Talk:Heartbleed/Archive 3

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1 Archive 2 Archive 3 Archive 4

Edit warring "request for reference"

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 [1]. 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

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

@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?

In this diff [2] 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. [3] 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)

Infographic in Impact

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

GA toolbox
Reviewing
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.
checkY All issues resolved.--¿3family6 contribs 20:22, 25 November 2014 (UTC)
  1. Pass/Fail:
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?

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)

Undid massive, undiscussed changes.

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.[4] In any case, I've reverted the misleading information.[5]] 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.[6] 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)

Not affected

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

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/\

External links modified

Hello fellow Wikipedians,

I have just modified 10 external links on Heartbleed. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:44, 31 October 2017 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Heartbleed. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:27, 20 January 2018 (UTC)

Featured article candidacy

I was looking for articles in WikiProject Computer Security that might make good featured article candidates, and I think this one would be a really solid choice. It's really well-referenced, clear, and complete. Anyone disagree with nominating it? FalconK (talk) 08:25, 6 October 2016 (UTC)

I'm not experienced enough to make this nomination myself, but I'm happy to provide assistance and technical expertise to anyone considering nominating this article (or any in {{TLS/SSL}} for that matter). TheDragonFire (talk) 05:02, 8 February 2018 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Heartbleed/Archive_3&oldid=1136273475"