Hint: you have to uncheck two checkboxes that OS X explicitly tells you about in the very same Spotlight preferences, plus another one in Location preferences.
What I meant with explicit was that they are explicitly described in the text that is shown on clicking the button called "About Spotlight Suggestions and Privacy."
If one would never even open Spotlight preferences, then yeah, it is not possible to see, enable or disable those preferences. But then one should also not complain that it is impossible to enable or disable these preferences. By that logic, every application that does anything with any privacy implications should have it's primary interface littered with preference toggles to make it completely obvious how it's functionality can be altered.
I think a basic warning, information or other type of system making a user aware, that all their searches are being shared with 3rd parties is not an unreasonable demand.
Having people go to two preferences dialogs just to find out that contents of search box are being sent to USA datacenters is a dangerous dark pattern.
Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between (released on the 26th I think?).
3-5 days is pretty decent considering that the DHCP stack on OS X isn't vulnerable and only customers that had enabled the apache2 instance and configured it with non-default mods were possibly affected.
More often than not Apple is removing GPL code from OS X altogether in the face of issues (example: samba is now replaced with 'smbx' in-house implementation).
I felt it was 50/50 that they'd update it vs. remove/disable it.
No way they'd remove it, there's probably hundreds of commercial software packages shipping with install scripts or even runtime scripts that depend on bash. That's a QA nightmare that would need to be planned across 1-2 annual major releases.
> Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between (released on the 26th I think?).
> 3-5 days is pretty decent ...
According to the timestamps on the GNU ftp site for bash, the first patch was released 2014-09-24 10:24 (unknown timezone).
Slackware had their first upgrade file-set out at Wed, 24 Sep 2014 16:37:00 -0700 (PDT) (for six different versions, in both i386 and x86_64 variants).
The second patch is timestamped 26-Sep-2014 17:02 on the GNU ftp site. Slackware's second upgrade file-set was out Thu, 25 Sep 2014 13:38:49 -0700 (PDT) (again with twelve different packages). [no idea why there is time travel here, likely the datestamp on the ftp site was subsequently updated for some reason]
The final patch is timestamped 27-Sep-2014 22:38 on the GNU site, and Slackware had out their third upgrade file-sets at Mon, 29 Sep 2014 12:33:36 -0700 (PDT).
Without knowing the FSF's timezone, we can only make estimates, but, for the first patch: same day, second patch: unknown, the time travel effect prevents making any estimates, third patch: about a day and a half.
And other distro's had patches out even earlier than Slackware, so, no, 3-5 days is _not_ pretty decent, it is actually downright poor.
Yeah, poor. How dare they go through their long established QA for something like this? How dare they do what literally every other company does.
Seriously, why do you think companies like Microsoft rather write workarounds to issues on their website instead of putting out a 2 line code fix for a given issue? Couldn't possibly be that their QA process would take so long that it is easier to just publish the work around, right?
Let me guess, Apple could not have done right by your standards. Had they just published a how-to in order to update bash by hand, you would bitch that this is insufficient. Had they published unstable versions of the fix (like your mentioned "other distros" did just so they could say they already have a fix) you would have piped up along the lines of "nice going publishing unstable fixes that probably introduce more leaks than they fix"
1) what difference would it have made, really, had apple distributed that first patch (that fixed one of 6 CVEs) instead of waiting for the second?
2) what attack vectors have you identified against an OSX system that exploit this vulnerability? (note that their dhclient imlpementation is not actually affected)
Even if you could find public servers running OS X that were exploitable, who would put effort into it? OS X also isn't glued together with scripts like a typical Linux system.
Kind of hard to remove Bash when it's the default shell and a great many scripts have been written targeting Bash features. Sure, there are other sh-compatible shells, but AFAIK they aren't 100% compatible with Bash.
Edit: If you disagree with me, please reply instead of downvoting.
How long ago did that happen? I know it uses Dash now but I'm not familiar with the shell history of Ubuntu.
Regardless, the difference is people who run Linux upgrade major versions intentionally (I assume the switch happened on a major version upgrade) and expect software packages to have to support their OS version. For example, the package manager keeps separate packages for each distribution.
OS X works differently. It's a customer OS, which people upgrade without reinstalling anything, and they expect their software to continue working. Furthermore, OS X software never targets specific OS versions, instead only targeting a minimum version, and software that works on one version of OS X is expected to work on the next version (any changes that break apps go through a deprecation process first, so the software has to be unmaintained for at least a major OS version before it will break).
Because of that, any software that relies on bash-specific functionality would break if bash were replaced, and it would generally be considered unacceptable.
What can be done is /bin/sh could be changed to another sh-compatible shell, but Bash would still have to be shipped on the system.
Ubuntu made the change for Ubuntu 6.10 (edgy), released in October 2006 (for those unfamiliar with the version scheme).
A slight correction to the poster before you: /bin/sh was linked to dash (making quite a few shellshock exploits fail on Ubuntu), while /bin/bash was the default user account shell... much as you've suggested!
On Yosemite:
$ /bin/sh --version
GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin14)
Copyright (C) 2007 Free Software Foundation, Inc.
So yes, anything that naively creates subprocesses using /bin/sh -c is open to shellshock exploits on (unpatched) OS X. :-)
Actually, saying "please reply instead of downvoting" does seem to help. Of course, my goal isn't meaningless karma, it's to find out why people think my comment is worth downvoting. The few times I've edited a comment to say "please reply instead of downvoting", the downvotes stopped, and people start replying instead.
Sometimes, yes. But my actual goal is to encourage dissenters to reply, because I actually want to know why they disagree with me. The karma itself is entirely meaningless except in that it affects how many people end up reading the comment.
The guidelines were written in order to make HN a better place for the entire HN community. Your defense of "please reply instead of downvoting" only touches upon how it "seems to help" you.
Encouraging discussion helps everyone. That's what the comments are for. The guidelines have that line in them because people do not like reading complaints about being downvoted, and because those complaints are not productive conversation. Not because there is some underlying reason why drawing attention to the existence of comment moderation is somehow wrong.
>Disclosure was on the 24th, today is the 29th. The patch had to be developed in-between
Apple didn't make the patch they just repackaged it. That's five days to write a dozen lines of script to update the shell. Every single GNU/Linux distro was patched the day of, get real.
>I felt it was 50/50 that they'd update it vs. remove/disable it.
Remove it for what ash/sh? Tim Cook doesn't know a megabit from a megabyte, let alone a shell. That pencil pusher doesn't care about his users, only the money. This was only patched for PR. Still no sight of it on the automatic updates list.
They demonstrated an easy way to deploy a Go application utilizing Docker ( https://docker.com/ ) and Google App Engine.
The Docker Engine container comprises just the application and its dependencies. It runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers. Thus, it enjoys the resource isolation and allocation benefits of VMs but is much more portable and efficient.
Which implements an http server - that's all, see here for more details:
https://godoc.org/net/http
It is not necessary, nevertheless possible, to use something like nginx or apache in front of a Go web application.
Hi gophers,
We've just released Go version 1.3.2, a minor point release.
This release includes bug fixes to cgo and the crypto/tls package.
https://golang.org/doc/devel/release.html#go1.3.minor
The crpyto/tls fix addresses a security bug that affects programs that use crypto/tls to implement a TLS server from Go 1.1 onwards. If the server enables TLS client authentication using certificates (this is rare) and explicitly sets SessionTicketsDisabled to true in the tls.Config, then a malicious client can falsely assert ownership of any client certificate it wishes. This issue was discovered internally and there is no evidence of exploitation.
You can download binary and source distributions from the Go web site:
https://golang.org/dl/
To compile from source using a Mercurial checkout, update to the release with "hg update release" and build as usual.
Thanks to everyone who contributed to the release.
Andrew
I recently installed the CE package and it was a good experience overall. I had put it in a VM though, because it didn't like my postgresql installation ( https://wiki.postgresql.org/wiki/Apt ).
Just make a monthly recurring entry in your calendar that says "Check SSL certificates".
If you rely on your calendar, it's simpler to create an entry in your calender for changing the certificate a few days prior to its expiration date. Monthly reminders will be ignored too easily.
