Re: Bug#990302: ITP: bulk-extractor -- A stream-based forensics tool for triage and cross-evidence analysis, which scans the media and extracts recognizable content
Hello Jan,
> Unfortunately the repository, that you reviewed is very much
> work-in-progress and it was not intended by me, that somebody else looks
> at it.
My bad, I had the wrong impression that it was ready for review, but
it's not that bad since I only did an overview anyway.
> Since I originally posted on the mailing list due to the licensing
> issues, which could be resolved by
>
> a) discussing with upstream
> b) reimplementing the JSON-scanner-code with libjson-c
Ah, I thought this one was solved (probably because I didn't read the
whole discussion on Github).
> I am aware of not using the network during the build. Actually I just
> copied the rules-file from the Kali-repo and did nothing else to it,
> sorry that you looked at it and wrote a thorough review about it, did
> not intend that, but thanks for that anyways.
No need to say sorry, it was a fault on my side but it wasn't a waste
of time anyway.
> I thought, I will package scaedan and dfxml as separate Debian packages,
> since they are generic and of use for others.
>
> If you don't know about dfxml, here is a short quote from the abstract
> of the original research paper:
>
> "Digital Forensics XML (DFXML) is an XML language that enables the
> exchange of structured
> forensic information. DFXML can represent the provenance of data
> subject to forensic
> investigation, document the presence and location of file systems,
> files, Microsoft
> Windows Registry entries, JPEG EXIFs, and other technical
> information of interest to the
> forensic analyst." [0]
>
> Furthermore, the NIST is concerned with dfxml [1]. Dfxml is currently
> primarily used by universities and analysts looking at the traces of
> applications, so I think, it would be a valuable addition Debian --
> independent of bulk_extractor, don't you think so?
Agree.
> Right now I am discussing and working with upstream on the organisation
> of the dfxml-project [1].
Ack, perks of working on Debian packaging, sometimes you get to
contribute upstream and before you know your name appears under
AUTHORS in some project :)
> - python3-dfxml: containing the python implementation of dfxml
> - python3-dfxml-tools : containing helpful tools building on the Python
> dfxml-implementation, like fiwalk, idifference and so on
> - libdfxml: containing the C++-implementation of dfxml as shared library
> as it is used by bulk_extractor (and maybe future software?!?)
> - scaedan: a package needed by bulk_extractor
>
> What do you think about it, do you think this is reasoable and that I
> will find a sponsors for those packages?
> If you think so, then I will file the corresponding ITPs in the course
> of the next week.
It seems very reasonable, yes, and I/we can sponsor them for you. Just
be careful when deciding if/to bundle some of those packages into a
single source package (it sounds like python3-dfxml and
python3-dfxml-tools come from the same sources).
> This is a great hint and it concerns be13_api. So if I understand
> correctly, I could just add the be13_api-submodule in the salsa-repo,
> right?
That's correct, but the way you do it matters; you have to repack
upstream's tarball to include the submodule and add the "-ds" suffix
to upstream's version, then import that new orig tarball into your
repo (you will also have to modify d/copyright things to explain the
repack). Tell me if you face any issues when you get to do it.
Thank you for your work!
--
Samuel Henrique <samueloph>
Reply to: