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>