FreeBSD support?

[llucps]

I'm trying to migrate from debian to FreeBSD and the main roadblock is not being able to use gocryptfs since the library https://github.com/hanwen/go-fuse doesn't compile on FreeBSD hanwen/go-fuse#415

Maybe it's a bit of stretch but could gcroptfs use this library on FreeBSD instead? Or it doesn't make sense what I'm proposing.

https://github.com/winfsp/cgofuse

Thanks

[rfjakob]

Hi, the platform support of https://github.com/winfsp/cgofuse is impressive.

Unfortunately, the API it provides is completely different to go-fuse.

[llucps]

It's a shame..

I started my journey trying to use FreeBSD and the only software that I cannot live without it is gocryptfs.. all the other alternatives (cryFS, secureFS etc..) do not provide the option to not encrypt the file names.. and this is crucial, so I can synchronize all my files across my computers and my private server with Unison

I even fiddled around with the linux binary support on FreeBSD and then copy the fusermount and fuse.mount to /bin and /sbin which seem to be used by gocrpytfs but they don't exist in FreeBSD. And I got everything working.. except for some reason the passwords can never be decrypted, it always says they are wrong. I even tried a bunch of option with gocryptfs init but nothing.

What's funny is using the master key it does mount but the mounted directory is empty.. I also saw a few errors in /var/logs/messages such:

kernel: linux: jid 0 pid 2479 (gocryptfs): unsupported fcntl cmd 1031

or

gocryptfs[4675]: doRead 298849: corrupt header: ParseHeader: invalid version, want=2 have=15475. Header hexdump: 3c7376672069643d224c617965725f312220 File hexdump (100 bytes): 3c7376672069643d224c617965725f312220646174612d6e616d653d224c6179657220312220786d6c6e733d22687474703a2f2f7777772e77332e6f72672f323030302f737667222076696577426f783d22302030203230302e37382035382e3934223e

So for the moment I gave up with the idea, although it's a shame because I really liked FreeBSD.

It would be great if someday there is a chance to run gocryptfs on FreeBSD.

Thank you anwyay.

[lechner]

I'll use that a plug for Guix. It reminds me of the BSD spirit, and some BSD tooling is popular there. Maybe it's worth an exploration.

[schlomie]

Just a heads up, there is now an open PR adding FreeBSD support in go-fuse.

[llucps]

FreeBSD support has been merged into go-fuse master branch. Let's hope someday will be able to add FreeBSD support for gocryptfs.

[rfjakob]

Nice! Whats missing for gocryptfs? Does it work?

…

On Tue, 23 Apr 2024, 19:15 llucps, ***@***.***> wrote: FreeBSD support has been merged into go-fuse master branch. Let's hope someday will be able to add FreeBSD support for gocryptfs. — Reply to this email directly, view it on GitHub <#741 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACGA756S372BFTUZD5ZH6LY62JJTAVCNFSM6AAAAAAYCGBHSCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TEMBTGY4TE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[llucps]

Unfortunately since I wanted to use gocryptfs I don't have a computer with FreeBSD installed. Hopefully someone else can test it.

[clausecker]

go-fuse supports FreeBSD as of v2.7.1, but the syscall bits require porting.

[schlomie]

Out of the box, it doesn't work quite yet.

# github.com/rfjakob/gocryptfs/v2/internal/syscallcompat
internal/syscallcompat/emulate.go:28:35: cannot use dev (variable of type int) as uint64 value in argument to syscall.Mknod
internal/syscallcompat/open_nofollow.go:28:52: undefined: O_PATH
internal/syscallcompat/open_nofollow.go:42:76: undefined: O_PATH
internal/syscallcompat/sys_common.go:102:8: undefined: Unix2syscall
internal/syscallcompat/sys_common.go:136:17: undefined: unix.ENODATA
# github.com/hanwen/go-fuse/v2/fs
../../../go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.5.2-0.20240412163214-90eabd702c26/fs/files.go:44:25: cannot convert (*loopbackFile)(nil) (value of type *loopbackFile) to type FileAllocater: *loopbackFile does not implement FileAllocater (missing method Allocate)
../../../go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.5.2-0.20240412163214-90eabd702c26/fs/files.go:211:13: f.utimens undefined (type *loopbackFile has no field or method utimens)
../../../go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.5.2-0.20240412163214-90eabd702c26/fs/bridge.go:257:2: undefined: setBlocks
../../../go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.5.2-0.20240412163214-90eabd702c26/fs/loopback.go:126:32: undefined: intDev
../../../go/pkg/mod/github.com/hanwen/go-fuse/v2@v2.5.2-0.20240412163214-90eabd702c26/fs/loopback.go:344:9: undefined: NewLoopbackDirStream

If I'm able to squeeze out a bit of free time, I might dig into it. It looks like what all was done in go-fuse were the necessary abstractions. Not sure the FreeBSD implementations are in place yet.

[rfjakob]

This should be fixed now via hanwen/go-fuse#509

[schlomie]

Looks like some gocryptfs changes will be necessary to support FreeBSD.

Pulling in master from go-fuse

$ go get github.com/hanwen/go-fuse/v2@master
go: upgraded github.com/hanwen/go-fuse/v2 v2.5.0 => v2.5.2-0.20240816120607-db8da281991c

Building

$ GOOS=freebsd go build
# github.com/rfjakob/gocryptfs/v2/internal/syscallcompat
internal/syscallcompat/emulate.go:28:35: cannot use dev (variable of type int) as uint64 value in argument to syscall.Mknod
internal/syscallcompat/open_nofollow.go:28:52: undefined: O_PATH
internal/syscallcompat/open_nofollow.go:42:76: undefined: O_PATH
internal/syscallcompat/sys_common.go:107:8: undefined: Unix2syscall
internal/syscallcompat/sys_common.go:141:17: undefined: unix.ENODATA

[schlomie]

syscall_linux.go

func Mknod(path string, mode uint32, dev int) (err error) {
	return Mknodat(_AT_FDCWD, path, mode, dev)
}

syscall_freebsd.go

func Mknod(path string, mode uint32, dev uint64) (err error) {
	return mknodat(_AT_FDCWD, path, mode, dev)
}

I will dig into this some more. Looks like some arch abstractions will be necessary in emulateMknodat or possibly higher up?

[clausecker]

The v2.7.1 release of go-fuse now supports FreeBSD. What is missing right now are only the platform-specific bits. Shouldn't be super hard to do!