The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC.
It is worse because it is HOL'd and requires additional resources to manage state persistence for idle TCP channels. The other solutions leverage stateless cookies without speculative tradeoffs inherent with sitting on idle sessions. This is a BFD when your servicing thousands of concurrent requests.
SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.
*Everything* implemented over TCP has head of line blocking issues. This property is inherent in the definition of a stream which is what TCP implements. The only way around it is multiple independent streams. It does not matter how the protocol is structured or what it does as long as it is doing it within a single TCP stream.
Head of line blocking is really only an issue for dynamic content.
Why?
Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests.
Even in the case where RFC7413 has not been deployed this isn't always true especially over low bandwidth/lossy links. If one stream has to eat RTT or worse RTO other streams can continue to transmit unimpeded. It is important to avoid cherry picking simulation results. Not all of them are positive.
Browsers on the other hand are supposed to take invalid HTML and try to do something useful with it. If browser developers didn't have to spend so much time trying to make their code interpret invalid syntax, they could probably fix a lot of the other bugs that actually affect valid code.
While it may well be more difficult to write an HTML parser this effort is an insignificant rounding error when considered within context of effort needed to produce a modern browser stack.
Thirteen years later, 95% of internet traffic is still IPv4. Ten or twenty years from now, do we want to be using a better version of HTTP, or still be using HTTP/1.1 and talking about HTTP/2?
I don't care if we're still using HTTP/1.0 a hundred years from now. IPv6 is actually needed to solve an actual problem and offers real benefit to users needing to directly communicate with their peers - especially those currently stuck behind carrier NATs lacking a global address of their own.
HTTP/2 isn't going to make anyone's online experience any better or faster. Even today with our quad core muti-ghz CPUs, GPUs, several GB ram, dozens mbits of bandwidth sites still take forever to load... the only thing that has changed instead of loading actual content more time is spent engaged in massive data collection and cross-domain spying. The problem that needs solving isn't technical it is political.
1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.
The Internet is a production network. You either deploy IPv6 fully in a production quality matter or don't do it at all. The mistake was in developing transition mechanisms in the first place which have done nothing but get in the way of adoption.
there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size.
Not everyone in the world has access to the same buying power enjoyed by rich western states. *Someone* ultimately has to pay for PI, rinky-dink multi-homing and lazy TE shenanigans. It is a political calculation whom that should be.
Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.
Reality is IPv6 privacy extensions were widely deployed in a landscape already dominated by browser fingerprinting, browser cookies, plugin cookies, DNS fingerprinting.
Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.
Completely disagree. RFC7413 is already an RFC unlike SPDY and already solves the problem of overhead for new requests using stateless cookies without keeping session state (e.g. tied up resources) open speculatively in anticipation of future reuse.
Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.
The same concept applied to TLS currently in the pipeline allows for requests to be processed by the application stack on the 0th round trip using HTTP/1.0 with no head of line blocking.
In essence deploying HTTP/2.0 is worse than simply addressing underlying deficiencies in TCP and TLS... Better still this effort carries forward and is reusable for other non HTTP based protocols.
The IETF like the UN is nothing more than meeting spaces for those with power to negotiate when it's in their best interests to do so.
I think it is unfortunate the principals IETF claims to stand for (technical merit over BS) are allowed to so easily be silenced by hand waving and procedural BS. Specifically it is laughable no appeal by anyone for any reason has ever succeeded within the IETF structure.
I've heard rumors this is not true yet having been subscribed to IETF announce for 10+ years and thumbing through appeals archive I could not find or recall a single example of any appeal ever succeeding. If you know otherwise I would love to hear about it.
The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38
IMO failure to implement BCP38 is no excuse for protocols to not sufficiently deal with the Internet as it exists today. Solution for DNS is the same solution previously applied to TCP to mitigate SYN exhaustion attacks.
All remaining deployed protocols susceptible to cheesy amplification attacks can and should be fixed regardless of status of BCP38. None of it is rocket science.
That's actually why I decided to use it. Faster compile times.
OS X hits the disk so often, that I moved my user environment on to the RAM drive.
Even with 1066 MHz RAM, I would get instant build times as the swap files were now in RAM.
That when compared to 30 second build times are a trade off I'm willing to make.
I/O limited compilers? More likely need to enable parallel builds to hide I/O latency.
So, yeah. Swap files on the RAM Disk. Insane speed as a result. Disk backed up to an SSD. Battery backup (laptops have batteries too, don't they?) Never a problem.
Unfortunately, there's currently no way for a site to say, "hey, I just changed my cert from an old one to a new one, don't mind the difference."
Or hey my cert got hacked and I need to install a new one...please believe me. I think what we need to do is push this out to the CAs probably using something similar to in-band OCSP to at least allow for unexpected changes while still locking down the hierarchy.
The top of my list is timing analysis of entered commands. You SSH into someplace and later type a password or something worth knowing. Timing between keystrokes can be used to recover information about what you are doing.
Every time I hear bureaucrats rumbling about "cyber security" only thing that comes to mind are schemes to legalize spying "for our own good"... Still seeing politicians getting airtime rambling about legislation to indemnify corporations for "sharing" information with the government not letting the Sony opportunity go to waste.
The military industrial complex has countless billions of dollars at its disposal and the only constructive thing I've seen out if it is US-CERT mailing list which for the most part delivers very little we didn't hear somewhere else first.
Most everything from what I have heard and seen from DHSs own website is structured for defense after the fact or screwing around with ridiculous hacker wargames as if cyberspace was somehow meaningfully analogous to meatspace.
They have all of the open source code, they have Microsoft source code, they can probably get source code from others if they asked nicely enough... They could use some of their money to find and plug holes before everyone gets owned or fund R&D efforts to improve the state of security technology... instead it is all reactionary masturbation.
Granted, not all of this requires the Internet, but the vacation thing does, and it's a perk I use way more than I though (I travel for work, and randomly visit friends fairly often, I don't waste gas, and I don't come home to a coldhouse )
My crummy old thermostat has a vacation hold setting you simply enter number of days you will be away and the normal schedule resumes after that time.
Other than a few people who have incompatible multistage heat pumps, and ignoring the sort of
Or **any** single stage heat pump. Setbacks with heat pumps cost you money. The most energy efficient means of heating and cooling in many regions is a heat pump... WTF NEST?!??
conformation bias by those who opted in early, there's still good savings to be had with a smart thermostat.
Connecting it to the internet makes it even more aware. It can save me more money if it knows I'm not coming home tonight, and not to bother heating up the house until I'm actually on my way.
I would like to see anyone cite a study establishing measurable savings on the use of NEST vs standard programmable thermostats.
Just a week ago a bigwig from NEST was interviewed on CNN saying NEST = 20% average savings...
There has got to be a study supportive of NESTs claims accessible to the public? Or perhaps you think antidotal BS in the form of the forum link you posted is a suitable alternative?
Most of us recognize you're as get-off-my-lawn of a regular as Slashdot has, but you might be missing the boat on something like Nest. It's a good product, and "works with Nest" is simply a sign that other manufacturers have realized it too.
I'm so tired of marketing bullshit and the people who parrot it. Those supporting NEST need to back up their claims with reality if they expect anyone to give two shits about what they have to say.
Don't recommend skipping the ad. If you do it automatically cycles compressor back on it shut off 3 seconds ago so you could better enjoy the ad (for new HVAC equipment).
... set up an automatic backup system for all your systems, now. Every system on your network should back itself up automatically daily, not only for this possibility but for all of the platform-agnostic ones such as hardware failure.
For me takeaway was regular manual backups to offline storage is important.
When malware has the ability to jump ship to network resources my guess very few "automatic" solutions deployed today are capable of denying remote commands to delete or overwrite online backups. Even offsite "cloud" solutions almost always include remote administrative capability that would have the affect of rendering backup medium worthless.
First she probably used WindowsXP which has dozens of unpatched vulnerabilities which will never be patched since it is EOL. XP has no concept of user priveldges outside of programs so all services run as admin for everything. Drivers too can run as hardware and it has no ASLR or ram scrambling to prevent overflow attacks or stack smashing.
Most home users are being exploited by social engineering rather than defects in the operating system.
Locking down PCs, reducing privileges, "attack surfaces"..etc is worthwhile yet default even with XP is a stealth mode firewall where very little of this shit even matters to external adversaries home users face. Various software and hardware memory guards to prevent exploitation of software defects continually demonstrate themselves to be insufficient even in latest versions of windows. While escalation of privilege is easier you can still cause a lot of damage running code as the user.
Do these and you eliminate 90% of infections.
90% = 1:10... Or to use slightly different wording out of any 10 untargeted infections your likely to still get one.
Oh and of course I use a standard user account. I have that and an admin account which is occasionally annoying with UAC but this helps and puts in another layer of security as now the payload will need to bypass this.
Oh wait I forgot - you can't blame the victim ever no matter how much of a stupid fucking idiot they are!
I blame our industry for being as you put it "stupid fucking idiots". The most common attack vector for this particular malware and many like it is email attachments.
It's 2015 anyone in the world can still send an email with file attachments to anyone using whatever FROM address they'd like without any prior trust relationship, vetting or authorization by receiver. Most mail clients let users execute it in the same security context as the user without so much as a peep.
It isn't the users fault they don't fully understand the depths to which the technology they are using is completely broken and wholly unsuitable for purposes for which it is used by countless millions on a daily basis.
It is *our* fault for installing AV software and going back to picking our noses. *MILLIONS* of people are being exploited using the same attack vectors with malware and spyware... this business of calling everyone "fucking idiots" is getting old.
The obvious solution is formally verified code. The airline industry can produce it, so it's not outrageously difficult to do. It is expensive, but so is patching SSL after getting hacked every year or so.
This wouldn't be the same industry busy rolling out untrusted "NextGen" navigation and communications standards?
Which Linux user actually got hacked by a library vulnerability this year?
Strange how this device creeps up now and then in unexpected contexts.
Well I can't think of one... so that must mean nobody?...... Right? No harm in drawing conclusions as my experience is a good enough proxy for the remainder of the world.
The thing is, sometimes the many eyes just aren't pointed in the right direction. A publicly disclosed vulnerability changes that instantly, hundreds or thousands of expert eyes to got work, fixes happen fast, and the community learns from the incident, often resulting in the eradication of a whole class of risks.
All of these new eyeballs must have forgotten to update the OpenSSL change log with their contributions.
I have never been a believer open source code is automatically more secure. Different projects have different code quality. Depends on if/how they are managed and who all is willing to step up contribute their time and effort.
There have been some advantages unique to open source projects such as static analysis vendors developing, testing and marketing their wares blessing a huge swatch of open source land with the fruits of their labor as well as the ability for savvy users to evaluate willingness to use software based on observation of code quality which can be difficult to discern from commercial software.
Yet for the most part for most of us mortals the end result is simply a function of who is willing to step up and contribute what.
Slashdot Mirror
The only reason you've given for HTTP/2.0 being worse is that it's not already an RFC.
It is worse because it is HOL'd and requires additional resources to manage state persistence for idle TCP channels. The other solutions leverage stateless cookies without speculative tradeoffs inherent with sitting on idle sessions. This is a BFD when your servicing thousands of concurrent requests.
SPDY and by extension HTTP/2.0 does not have head of line blocking issues. The requests are multiplexed, but tagged, and requests can be answered out of order.
*Everything* implemented over TCP has head of line blocking issues. This property is inherent in the definition of a stream which is what TCP implements. The only way around it is multiple independent streams. It does not matter how the protocol is structured or what it does as long as it is doing it within a single TCP stream.
Head of line blocking is really only an issue for dynamic content.
Why?
Pipelining all of your static resources through a single connection to a single subdomain is more efficient than multiple requests.
Even in the case where RFC7413 has not been deployed this isn't always true especially over low bandwidth/lossy links. If one stream has to eat RTT or worse RTO other streams can continue to transmit unimpeded. It is important to avoid cherry picking simulation results. Not all of them are positive.
Browsers on the other hand are supposed to take invalid HTML and try to do something useful with it. If browser developers didn't have to spend so much time trying to make their code interpret invalid syntax, they could probably fix a lot of the other bugs that actually affect valid code.
While it may well be more difficult to write an HTML parser this effort is an insignificant rounding error when considered within context of effort needed to produce a modern browser stack.
Thirteen years later, 95% of internet traffic is still IPv4. Ten or twenty years from now, do we want to be using a better version of HTTP, or still be using HTTP/1.1 and talking about HTTP/2?
I don't care if we're still using HTTP/1.0 a hundred years from now. IPv6 is actually needed to solve an actual problem and offers real benefit to users needing to directly communicate with their peers - especially those currently stuck behind carrier NATs lacking a global address of their own.
HTTP/2 isn't going to make anyone's online experience any better or faster. Even today with our quad core muti-ghz CPUs, GPUs, several GB ram, dozens mbits of bandwidth sites still take forever to load... the only thing that has changed instead of loading actual content more time is spent engaged in massive data collection and cross-domain spying. The problem that needs solving isn't technical it is political.
1: mechanisms for interoperability were bolted on later, not included as core features that every client and router should support and enable by default. The result is that relays for the transition mechanisms are in seriously short supply on the internet and often cause traffic to be routed significantly out of it's way.
The Internet is a production network. You either deploy IPv6 fully in a production quality matter or don't do it at all. The mistake was in developing transition mechanisms in the first place which have done nothing but get in the way of adoption.
there was lots of dicking around with trying to solve other problems at the same time rather than focusing on the core problem of address shortage. For example for a long time it was not possible to get IPv6 PI space because of pressure from people who wanted to reduce routing table size.
Not everyone in the world has access to the same buying power enjoyed by rich western states. *Someone* ultimately has to pay for PI, rinky-dink multi-homing and lazy TE shenanigans. It is a political calculation whom that should be.
Stateless autoconfiguation and the elimination of NAT seemed like good things at the time but they raised privacy issues and added considerable complexity to home/small buisness deployments.
Reality is IPv6 privacy extensions were widely deployed in a landscape already dominated by browser fingerprinting, browser cookies, plugin cookies, DNS fingerprinting.
Part of the reasons for dozens of (sub)domains is because even modern browsers still have a connection limit per host. And there's a lot of overhead in establishing an HTTP connection. If you're loading lots of tiny files, it makes sense to download them all through one HTTP connection. HTTP/1.1 already has pipelining, but almost no server is set up to use it.
Completely disagree. RFC7413 is already an RFC unlike SPDY and already solves the problem of overhead for new requests using stateless cookies without keeping session state (e.g. tied up resources) open speculatively in anticipation of future reuse.
Multiplexing multiple streams within a single stream = Head of Line blocking. A problem that does not exist when using multiple independent streams are employed.
The same concept applied to TLS currently in the pipeline allows for requests to be processed by the application stack on the 0th round trip using HTTP/1.0 with no head of line blocking.
In essence deploying HTTP/2.0 is worse than simply addressing underlying deficiencies in TCP and TLS... Better still this effort carries forward and is reusable for other non HTTP based protocols.
The IETF like the UN is nothing more than meeting spaces for those with power to negotiate when it's in their best interests to do so.
I think it is unfortunate the principals IETF claims to stand for (technical merit over BS) are allowed to so easily be silenced by hand waving and procedural BS. Specifically it is laughable no appeal by anyone for any reason has ever succeeded within the IETF structure.
I've heard rumors this is not true yet having been subscribed to IETF announce for 10+ years and thumbing through appeals archive I could not find or recall a single example of any appeal ever succeeding. If you know otherwise I would love to hear about it.
The biggest issue that's hit ntpd in the last year was the ease with which you could use the 'monlist' command for amplification attacks. This too was easily solved with a configuration change and in any event did not compromise the integrity of the servers running ntpd. It's symbolic of a larger problem that has hit other protocols (DNS) and which will never go entirely away until network operators get off their lazy asses and implement the recommendations of BCP38
IMO failure to implement BCP38 is no excuse for protocols to not sufficiently deal with the Internet as it exists today. Solution for DNS is the same solution previously applied to TCP to mitigate SYN exhaustion attacks.
https://tools.ietf.org/html/dr...
All remaining deployed protocols susceptible to cheesy amplification attacks can and should be fixed regardless of status of BCP38. None of it is rocket science.
That's actually why I decided to use it. Faster compile times.
OS X hits the disk so often, that I moved my user environment on to the RAM drive.
Even with 1066 MHz RAM, I would get instant build times as the swap files were now in RAM.
That when compared to 30 second build times are a trade off I'm willing to make.
I/O limited compilers? More likely need to enable parallel builds to hide I/O latency.
So, yeah. Swap files on the RAM Disk. Insane speed as a result. Disk backed up to an SSD. Battery backup (laptops have batteries too, don't they?) Never a problem.
Page file + ram disk = oxymoron
How long can you sustain these kinds of I/O rates before burning the thing out?
Awesome it is so fast yet like LTE with tiny data caps utility appears to be substantially constrained by limitations on use.
For subset of people with workloads actually needing this kind of performance how useful is this? Reads can be cached by DRAM which is quite cheap.
For those who don't really need it I can understand how it would be nice to have.
Unfortunately, there's currently no way for a site to say, "hey, I just changed my cert from an old one to a new one, don't mind the difference."
Or hey my cert got hacked and I need to install a new one...please believe me. I think what we need to do is push this out to the CAs probably using something similar to in-band OCSP to at least allow for unexpected changes while still locking down the hierarchy.
It's discussed in the article under "Traffic analysis resistance"
Not that I agree with the method...
Disagree this talks only about hiding yourself using TOR.
This does not work against adversaries with access to YOUR pipe (e.g. NSA) before it hits TOR.
The top of my list is timing analysis of entered commands. You SSH into someplace and later type a password or something worth knowing. Timing between keystrokes can be used to recover information about what you are doing.
It can be done with microphones..
http://berkeley.edu/news/media...
It can be done with clocks..
http://users.ece.cmu.edu/~dawn...
Every time I hear bureaucrats rumbling about "cyber security" only thing that comes to mind are schemes to legalize spying "for our own good" ... Still seeing politicians getting airtime rambling about legislation to indemnify corporations for "sharing" information with the government not letting the Sony opportunity go to waste.
The military industrial complex has countless billions of dollars at its disposal and the only constructive thing I've seen out if it is US-CERT mailing list which for the most part delivers very little we didn't hear somewhere else first.
Most everything from what I have heard and seen from DHSs own website is structured for defense after the fact or screwing around with ridiculous hacker wargames as if cyberspace was somehow meaningfully analogous to meatspace.
They have all of the open source code, they have Microsoft source code, they can probably get source code from others if they asked nicely enough... They could use some of their money to find and plug holes before everyone gets owned or fund R&D efforts to improve the state of security technology... instead it is all reactionary masturbation.
Granted, not all of this requires the Internet, but the vacation thing does, and it's a perk I use way more than I though (I travel for work, and randomly visit friends fairly often, I don't waste gas, and I don't come home to a coldhouse )
My crummy old thermostat has a vacation hold setting you simply enter number of days you will be away and the normal schedule resumes after that time.
Other than a few people who have incompatible multistage heat pumps, and ignoring the sort of
Or **any** single stage heat pump. Setbacks with heat pumps cost you money. The most energy efficient means of heating and cooling in many regions is a heat pump... WTF NEST?!??
conformation bias by those who opted in early, there's still good savings to be had with a smart thermostat.
Connecting it to the internet makes it even more aware. It can save me more money if it knows I'm not coming home tonight, and not to bother heating up the house until I'm actually on my way.
I would like to see anyone cite a study establishing measurable savings on the use of NEST vs standard programmable thermostats.
Just a week ago a bigwig from NEST was interviewed on CNN saying NEST = 20% average savings...
There has got to be a study supportive of NESTs claims accessible to the public? Or perhaps you think antidotal BS in the form of the forum link you posted is a suitable alternative?
Most of us recognize you're as get-off-my-lawn of a regular as Slashdot has, but you might be missing the boat on something like Nest. It's a good product, and "works with Nest" is simply a sign that other manufacturers have realized it too.
I'm so tired of marketing bullshit and the people who parrot it. Those supporting NEST need to back up their claims with reality if they expect anyone to give two shits about what they have to say.
Where is the insight here? Other than the clear insight into the poster's fear of experimental, new technologies and applications.
Experimental? Is that written somewhere on the side of the box?
Skip ad in 3 seconds...
Don't recommend skipping the ad. If you do it automatically cycles compressor back on it shut off 3 seconds ago so you could better enjoy the ad (for new HVAC equipment).
This is some funny shit.
http://edition.cnn.com/videos/...
... set up an automatic backup system for all your systems, now. Every system on your network should back itself up automatically daily, not only for this possibility but for all of the platform-agnostic ones such as hardware failure.
For me takeaway was regular manual backups to offline storage is important.
When malware has the ability to jump ship to network resources my guess very few "automatic" solutions deployed today are capable of denying remote commands to delete or overwrite online backups. Even offsite "cloud" solutions almost always include remote administrative capability that would have the affect of rendering backup medium worthless.
First she probably used WindowsXP which has dozens of unpatched vulnerabilities which will never be patched since it is EOL. XP has no concept of user priveldges outside of programs so all services run as admin for everything. Drivers too can run as hardware and it has no ASLR or ram scrambling to prevent overflow attacks or stack smashing.
Most home users are being exploited by social engineering rather than defects in the operating system.
Locking down PCs, reducing privileges, "attack surfaces"..etc is worthwhile yet default even with XP is a stealth mode firewall where very little of this shit even matters to external adversaries home users face. Various software and hardware memory guards to prevent exploitation of software defects continually demonstrate themselves to be insufficient even in latest versions of windows. While escalation of privilege is easier you can still cause a lot of damage running code as the user.
Do these and you eliminate 90% of infections.
90% = 1:10... Or to use slightly different wording out of any 10 untargeted infections your likely to still get one.
Oh and of course I use a standard user account. I have that and an admin account which is occasionally annoying with UAC but this helps and puts in another layer of security as now the payload will need to bypass this.
http://xkcd.com/1200/
Oh wait I forgot - you can't blame the victim ever no matter how much of a stupid fucking idiot they are!
I blame our industry for being as you put it "stupid fucking idiots". The most common attack vector for this particular malware and many like it is email attachments.
It's 2015 anyone in the world can still send an email with file attachments to anyone using whatever FROM address they'd like without any prior trust relationship, vetting or authorization by receiver. Most mail clients let users execute it in the same security context as the user without so much as a peep.
It isn't the users fault they don't fully understand the depths to which the technology they are using is completely broken and wholly unsuitable for purposes for which it is used by countless millions on a daily basis.
It is *our* fault for installing AV software and going back to picking our noses. *MILLIONS* of people are being exploited using the same attack vectors with malware and spyware... this business of calling everyone "fucking idiots" is getting old.
http://en.wikipedia.org/wiki/C...
The obvious solution is formally verified code. The airline industry can produce it, so it's not outrageously difficult to do. It is expensive, but so is patching SSL after getting hacked every year or so.
This wouldn't be the same industry busy rolling out untrusted "NextGen" navigation and communications standards?
Which Linux user actually got hacked by a library vulnerability this year?
Strange how this device creeps up now and then in unexpected contexts.
Well I can't think of one... so that must mean nobody? ...... Right? No harm in drawing conclusions as my experience is a good enough proxy for the remainder of the world.
The thing is, sometimes the many eyes just aren't pointed in the right direction. A publicly disclosed vulnerability changes that instantly, hundreds or thousands of expert eyes to got work, fixes happen fast, and the community learns from the incident, often resulting in the eradication of a whole class of risks.
All of these new eyeballs must have forgotten to update the OpenSSL change log with their contributions.
I have never been a believer open source code is automatically more secure. Different projects have different code quality. Depends on if/how they are managed and who all is willing to step up contribute their time and effort.
There have been some advantages unique to open source projects such as static analysis vendors developing, testing and marketing their wares blessing a huge swatch of open source land with the fruits of their labor as well as the ability for savvy users to evaluate willingness to use software based on observation of code quality which can be difficult to discern from commercial software.
Yet for the most part for most of us mortals the end result is simply a function of who is willing to step up and contribute what.