Mac OS X support

[rfjakob]

Go support Mac OS X, as does the FUSE library we use, go-fuse.

gocrypts may actually work out of the box on OSX, but there probably are small issues that have to be sorted out.

At the very least, gocryptfs has to be tested on OSX. As I do not have a Mac to test on, this would be an opportunity for somebody from the Mac community to step up. Please comment here if you are interested.

[hasit]

I am interested in helping on this as much as I can. I will try to run it and comment back with what I find.

[rfjakob]

Hi @hasit, great to hear that!

[netheril96]

One thing it might have omitted is encryption of extended attributes. OS X makes extensive usage of extended attributes. For example, when you download a file with Google Chrome or Safari, the file will be marked with its original URL. When I tried EncFS before, the encrypted file always had the same extended attributes as the decrypted one, and thereby the plaintext could be easily obtained. I suspect the encryption of extended attribute will never cross the mind of regular Linux folk.

[rfjakob]

Extended attributes are not implemented yet in gocryptfs. I don't know how big a problem that is on OSX, but at least we cannot leak data ;)

[spaghetti2514]

Attempting to install on OS X 10.11.2 with go get github.com/rfjakob/gocryptfs, I get the following

# github.com/rfjakob/gocryptfs/cryptfs
.go/src/github.com/rfjakob/gocryptfs/cryptfs/openssl_aead.go:35: undefined: openssl.NewGCMEncryptionCipherCtx
.go/src/github.com/rfjakob/gocryptfs/cryptfs/openssl_aead.go:76: undefined: openssl.NewGCMDecryptionCipherCtx
# github.com/hanwen/go-fuse/fuse/nodefs
.go/src/github.com/hanwen/go-fuse/fuse/nodefs/files_darwin.go:5: imported and not used: "time"
.go/src/github.com/hanwen/go-fuse/fuse/nodefs/syscall.go:11: undefined: syscall.SYS_UTIMENSAT

[rfjakob]

@spaghetti2514 : Interesting. Can you run "openssl version" and post the output?

[spaghetti2514]

@rfjakob OpenSSL 1.0.2e 3 Dec 2015

[spaghetti2514]

I should point out that this probably has more to do with
https://github.com/spacemonkeygo/openssl/blob/master/ciphers_gcm.go#L15
than my openssl version

Removing the ",!darwin" part of that line eliminates those two errors for me

[rfjakob]

I guess the "!darwin" is because openssl was too old in an earlier OSX
version. But 1.0.2e is very recent, can you file a bug against
spacemonkeygo/openssl?

On Thu, Jan 7, 2016 at 1:34 AM, spaghetti2514 notifications@github.com
wrote:

I should point out that this probably has more to do with
https://github.com/spacemonkeygo/openssl/blob/master/ciphers_gcm.go#L15
than my openssl version

Removing the ",!darwin" part of that line eliminates those two errors for
me

—
Reply to this email directly or view it on GitHub
#15 (comment).

[spaghetti2514]

1.0.2e is very recent because I installed it very recently. It is not the native OS X openssl because the native OS X openssl no longer exists. Apple deprecated the use of openssl a long time ago in favor of their own crypto libs, and finally stopped shipping openssl completely in 10.11. OS X users that still build things against openssl tend to install it from homebrew, an unofficial package manager for OS X.

I am unsure if excluding OS X in the build process should be considered a bug, since the only reason it works for me is that I'm building openssl myself via homebrew.
On the other hand, there is no longer an official openssl shipped with OS X at all, so maybe that should be assumed.
Still want me to open a bug report?

[rfjakob]

In that case, it makes no sense at all anymore to exclude gcm from the build. Yes please file a ticket. I will take care of the other two issues as I am afraid I have caused them.

[spaghetti2514]

I have filed a ticket.

What other two issues are you referring to? just the unused time import and SYS_UTIMENSAT problems in go-fuse?

I think we'll run into other problems after that, as commenting some of that out to try to get farther along in the build reveals other build errors, but I can't be certain that they're not being caused by the way I'm stepping around previous errors.
Would you like me to wait until you've properly fixed the SYS_UTIMENSAT issue before checking for other errors?