search

forensicmatt / libtsk-rs

Wrapper for TSK (Sleuth Kit) Bindings
Apache License 2.0
11 stars 5 forks source link

Project status and contributing #4

Open yoavk opened 3 years ago

yoavk commented 3 years ago

Hi! This repo is awesome, and I'd love to use it! What's the status of this project? (I want to use it in order to read files - similar to test_copy_file)

I'd be happy to contribute and help move this project forward.

I was playing around with it, and was thinking to start with a PR to touchup the sleuthkit compilation for windows (with added support for x86 and v140 toolset). wdyt?

Also, any plans on publishing this to crates.io?

Thanks!

forensicmatt commented 3 years ago

Sorry for the delay. Sounds great! I will look at your PR this weekend. I actually could use a lot of help with the compiling TSK portion as I lack C skills.

Here are items I am thinking to get a stable first version out:

forensicmatt commented 3 years ago

I would like to have this available on crates.io but how does this working with needing the TSK libraries? I feel it would be hard to compile straight from source because there are so many build dependencies. I am very open to suggestions to handle these types of hurdles.

forensicmatt commented 3 years ago

I think this is a model we could use? https://github.com/denoland/rusty_v8#binary-build

yoavk commented 3 years ago
  • [ ] build script can compile libtsk with additional libs (EWF, etc)

I'm not sure how exactly this would work - do we need the additional libs to have their own rust crates? (for example - what happens if we use openssl and libtsk - we would end up having 2 separate compilations of the libraries :/)

  • [ ] auto tests with ci

We could easily add a GitHub action that build and runs the testsuite (see https://github.com/actions-rs/cargo)

  • [ ] split auto-generated bindings from rust wrappers (much like https://github.com/skade/leveldb and https://github.com/skade/leveldb-sys). This should help on the compiling front. I would like to have this available on crates.io but how does this working with needing the TSK libraries? I feel it would be hard to compile straight from source because there are so many build dependencies. I am very open to suggestions to handle these types of hurdles.

From what I've seen (in openssl for example), we could easily publish a crate that contains the source itself. There are even some packages which are split into 3 crates:

But I think one of the main reasons for this is to allow you to use an existing library already installed on the system. imo in our case that would be overkill, and we could keep it to either a single crate (just publish this whole repo), or split it to rust wrappers and source+build+bindings.

yoavk commented 3 years ago

I think this is a model we could use? https://github.com/denoland/rusty_v8#binary-build

I think the main question is do we need to support linking to an existing libtsk. otherwise - let's always compile from source (and then we don't need to separate crates or deal with env variables etc.)

forensicmatt commented 3 years ago

I'm not sure how exactly this would work - do we need the additional libs to have their own rust crates? (for example - what happens if we use openssl and libtsk - we would end up having 2 separate compilations of the libraries :/)

I don't think so. libtsk is using the additional libraries, not our wrappers, thus, I don't think we would need to do anything in rust with them. By chance, have you been able to compile libtsk with all the additional library support so it has ewf/vhd support?

forensicmatt commented 3 years ago

I think this is a model we could use? https://github.com/denoland/rusty_v8#binary-build

I think the main question is do we need to support linking to an existing libtsk. otherwise - let's always compile from source (and then we don't need to separate crates or deal with env variables etc.)

I guess we don't if we can streamline the build process.

yoavk commented 3 years ago

I'm not sure how exactly this would work - do we need the additional libs to have their own rust crates? (for example - what happens if we use openssl and libtsk - we would end up having 2 separate compilations of the libraries :/)

I don't think so. libtsk is using the additional libraries, not our wrappers, thus, I don't think we would need to do anything in rust with them. By chance, have you been able to compile libtsk with all the additional library support so it has ewf/vhd support?

I'll give it a try later this week. I think it might require using a different PlatformToolset (it looks like nuget downloads precompiled versions of openssl for v140 or v141, so we'd probably need to use the same toolset when calling msbuild)