Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Audit Unsafe #4485
Given #4483, we need to audit all usages of unsafe. We generally avoid it but some of the libraries we use use it.
Mostly exported from go-ipfs. However, I've asked the reporter in #4483 to try disabling it to see if that fixes it.
Used to compare pointers to avoid a deadlock.
Used to do a fast XOR. Looks safe.
Used all over the place and go vet complains that it's used incorrectly. I don't believe we use bbloom in any critical places so we can probably switch to bloom (made by the same author without unsafe).
Unclear but probably well vetted. I'm in the process of upgrading this library anyways (so if there are any missing bug fixes, that should pull them in).
Made by the go authors. Regardless we should update this.
We should try to upgrade to the latest version everywhere anyways.
Their mmap code looks fine. I'm mostly worried about the skip-list implementation. However, I doubt the user in #4483 has badger enabled.
However, we don't use this so it's definitely not causing any issues.
On the other hand, it looks like it may be doing unaligned loads (problem on arm?).
Used on windows for syscalls. Definitely safe.
The memory backend uses unsafe. However, it looks like it's just using it to atomically swap pointers. From what I can tell, this all looks safe.
Probably safe. Might as well update.
Uh.... Yeah. This one's going to be hard to audit. We should just update it and hope.
Written by the go authors. However, we should update it.
pb (progress bar)
Only uses unsafe for a few simple ioctls. Unlikely to be an issue.
For testing, looks fine bug I don't particularly care.
For performance reasons, I'd like to update gogo protobuf for everything except pbnodes anyways (which we may be able to just parse manually).
How hard do you think the switch will be? I have no experience with this area.
From what I can recall it is structured differently from our current FUSE library. It might make sense to extract FUSE support out of go-ipfs if we decide to change the lib (we wanted to do that for a long time).
I'm okay with using separate dependencies for separate platforms, but if a big move is planned anyway, it may be best to try and unify things in the process.
@djdv friend of mine is figuring out FUSE support using CoreAPI as a plugin to go-ipfs (until we have transport for CoreAPI) and extract it later.
IMO mounting support currently is not that high priority (I think there are more pressing issues on Windows). I also think that even in case of Linux it is closer to PoC than a complete feature.
I've tried this before but have had poor experiences with my own ipfs repo, it seems to work fine for small ones but with mine it seems to choke. It has been some time though, maybe it is better now, I will give it a go.
Agreed, the intention is to think more on that later. When FUSE is being discussed I have to chime in though, I don't want Windows to be left behind. ;^)