Re: sources.list 4 bullseye-security
On Sat, Jul 3, 2021 at 9:31 PM Salvatore Bonaccorso wrote: > I have pushed > https://salsa.debian.org/webmaster-team/webwml/-/commit/4ca2253325130f7e96bf2644d31cf5a95fdf7bcc Note that updating translations at the same time as the English page causes more work for the translation teams, who have to bump the translation check header. If you first commit the English change and then commit the translation changes, you can use ./smart_change.pl (see --help for instructions) to bump the translation check headers in the second commit. > Once bullseye will be released the example sources.list entry in > https://www.debian.org/security/#keeping-secure will need to be > adapted as well to match bullseye's sources.list entry for the > security archive. I've made a commit that means this will be automatically updated at release time: https://salsa.debian.org/webmaster-team/webwml/-/commit/06a365347b5545c26d162ef4887514d171f5dcd0 -- bye, pabs https://wiki.debian.org/PaulWise
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
Re: sources.list 4 bullseye-security
Hi, On Sun, Jun 27, 2021 at 04:52:26PM -0400, Boyuan Yang wrote: > Hi, > > (This email originally appears on > https://lists.debian.org/debian-www/2021/05/msg00017.html ) > > 在 2021-05-15星期六的 12:47 +0200，Harald Dunkel写道： > > Hi folks, > > > > Obviously > > > > https://wiki.debian.org/NewInBullseye > > and > > https://www.debian.org/releases/bullseye/errata > > > > disagree about the bullseye-security entry in sources.list. Not to > > mention that the deb-src line is missing on both. > > TL;DR: Both will work: > > deb http://security.debian.org/debian-security bullseye-security main > deb http://security.debian.org/ bullseye-security main > > Besides, I believe end users are not supposed to know deb-src line for > security repos. Adding such info provides zero benefit except for confusing > users. > > > I would highly appreciate a web page listing a full sources.list > > file for bullseye, > > I am forwarding your email to the security team in case they want a unified > format on Debian webpages (www.debian.org and wiki.debian.org). Please contact > the Debian WWW Team if a change is needed. Please use the form which is used in the release-notes: https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive I have pushed https://salsa.debian.org/webmaster-team/webwml/-/commit/4ca2253325130f7e96bf2644d31cf5a95fdf7bcc . Once bullseye will be released the example sources.list entry in https://www.debian.org/security/#keeping-secure will need to be adapted as well to match bullseye's sources.list entry for the security archive. Regards, Salvatore
External check
CVE-2021-3631: RESERVED -- The output might be a bit terse, but the above ids are known elsewhere, check the references in the tracker. The second part indicates the status of that id in the tracker at the moment the script was run.
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 Samuel, thanks for your message. On 03.07.21 01:39, Samuel Henrique wrote: Hello Jan, This would be a great package to have it on Debian, Happy to hear that! I usually do a quick review to see if I spot any noticeable issues before I do a deep dive on it (which I would to during this weekend), and I notice an issue on d/rules, there are some commands doing: "test -d foo || git clone bar" 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. 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 This is an issue because it goes against our policy of not using network during the build process[0], you can read a recent discussion about it on LWN as well[1]: "For packages in the main archive, no required targets may attempt network access, except, via the loopback interface, to services on the build host that have been started by the build." In order to fix this issue you have two options: 1) Package those projects separately and add them to B-D. 2) Repack the upstream tarball and vendor/bundle them in. You would usually prefer option 1 when the libraries could be reused by other packages and option 2 when they are likely to only be used by your package (usually means the same upstream). But sometimes, even if the library could be used by another package in the future (but it's not currently), you can go with option 1 if it makes more sense. Beware that there is not a clear consensus on this matter so some arguing might be needed (even though we have examples of packages vendoring libraries which are already available in a standalone manner on main). Looking at the three libraries we are talking about: simsong/be13_api simsong/dfxml (watchout cause it looks like this one has just been moved to a different repo) nbeebe/sceadan It looks like it's totally fine to vendor be13_api and dfxml, it seems like sceadan is generic enough to be used by other projects but I didn't do a proper check. I suggest you consider the options here and let us know what you think it's best. 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. 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? Right now I am discussing and working with upstream on the organisation of the dfxml-project [1]. Simson Garfinkel and Alex Nelson -- the upstream authors -- decided to build up language-specific repositories on my proposal and relocated the projects under a Github group-account called dfxml-working-group [2]. There is still some work to do, before we are ready to create a package from it -- a first step was to build it as a dynamically linked shared library. Currently, I have the plan to create the following packages for Debian's package archives: - 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. Oh, and since you are in contact with upstream, this sort of issue is sometimes solved by upstream providing a release tarball that includes the submodules. The issue is that as far as I know Github does not provide this feature, so they have to use a script to generate the tarball and attach it to the release. This makes the tarball easier to be worked on/packaged by other distros as well[2], but it's also easy for us to workaround so this is a
