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!

[ankushjp]

Hi,

I've attempted to add support for FreeBSD on the freebsd-support branch on a fork of the project here.

I've done a basic test with initialising a cipher directory, mounting it and creating some files and directories in the mounted plain directory, un-mounting and remounting to confirm the files and directories are still present and intact.

It looks like it's working so far based on this brief test. I don't daily-drive FreeBSD, so it's unlikely I'll be able to test this port extensively - I'm not sure how much more testing (if any?) is required before this can be considered ready to merge (did the Mac OS port get much testing before being merged? Maybe that can be used as an indication?).

Any feedback is much appreciated, especially if someone has a better understanding of / familiarity with the system calls available on FreeBSD. At the moment, a number of functions in internal/syscallcompat (e.g. Renameat2) are partially implemented (in terms of the Linux functionality in the syscallcompat package), or simply stubbed (e.g. EnospcPrealloc).

Thanks.

[schlomie]

This is fantastic, @ankushjp ! I've done a little testing, and everything seems to be working as expected. I'll keep it going for a while, and run it through various workflows, see what I can find, but I don't see any reason why a PR, (or at least one tagged with WIP) couldn't be opened now. Hopefully get more eyes on it than just from this discussion thread.

Thank you for this!

[rfjakob]

Nice. @ankushjp want to create a pull request?

[rfjakob]

It should be compile-tested in ci. In other words, add freebsd to crossbuild.bash

[ankushjp]

Thanks for the feedback @schlomie and @rfjakob - I've added the FreeBSD build to the crossbuild.bash script, and created a pull request.