Applying for Debian Developer
Hello everyone, I have been contributing to the pkg-security team since last year and have decided to apply for Debian Developer, uploading. If you would like to review my work, I have contributed these packages: ╭─╮ │ Team Upload: │ │ - arpon - p0f │ │ - dfdatetime- rephrase│ │ - libfsntfs - sleuthkit │ │ - librtr- tableau-parm│ │ - libvhdi - xprobe │ │ - libvmdk │ ╰─╯ Finally, If you think I am ready to be DD, please advocate me: https://nm.debian.org/process/935/advocate/ Thanks a lot! Best regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Request for review/upload of stegseek 0.5-1~exp1
Hello team, I'm looking for a sponsor for a new package, stegseek [1]. Please, could you review and upload it for the experimental? Thanks! [1] https://salsa.debian.org/pkg-security-team/stegseek Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Last days before the soft freeze
Hi Samuel, Samuel Henrique: > Hello Francisco, > >> tableau-parm (https://salsa.debian.org/pkg-security-team/tableau-parm), >> rephrase (https://salsa.debian.org/pkg-security-team/rephrase), >> xprobe (https://salsa.debian.org/pkg-security-team/xprobe), >> p0f (https://salsa.debian.org/pkg-security-team/p0f) and >> arpon https://salsa.debian.org/pkg-security-team/arpon. > > Awesome, thanks for working on them! > > I have only two small notes from the reviews, I have applied the > changes myself and sponsored all of them but it's worth noting: > > rephrase: sometimes when building with Rules-Require-Root set to false > fails, the reason is either d/rules or makefile trying to change > either the permissions or owner of files, and most of these times this > operation doesn't have any effect as debhelper will set the correct > attributes for the files. > This happened to be the case with rephrase, so this is the patch I > used to enable "Rules-Require-Root : no": > https://salsa.debian.org/pkg-security-team/rephrase/-/commit/49b9ba0e696fb4ccac93d23c028f1b367f52c8a3 Thanks for clarifying and for the patch. > > arpon: skip-systemd-native-flag-missing-pre-depends: Lintian was > throwing this warning so I added the "Pre-Depends" field as requested > by it. Thanks. > > Once again, thanks for your work :) > I thank you. -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Request to review and upload libvhdi 20201204-3
Hello Team, Sebastien recently applied the patch to disable the memory test on riscv64, this on libvhdi (https://salsa.debian.org/pkg-security-team/libvhdi). I saw that in other architectures the test continues to fail (https://buildd.debian.org/status/package.php?p=libvhdi). I took advantage of the same patch and add the failed arch's (https://bugs.debian.org/981333). I followed the same logic used to disable the memory test on riscv64, see bug #978528, and added predefined GCC macro(s) for: alpha = __alpha__ arm64 = __aarch64__ powerpc = __powerpc__ ppc64 = __ppc64__ ppc64el = __ppc64le__ s390x = __s390x__ I built it locally on arm64, but couldn't confirm on the other architectures. As a reference, it seems that it is okay to disable memory tests, (https://github.com/libyal/libpff/issues/94) "These tests are mainly intended as functional tests for CI not as build/deployment tests how Debian seems to be using them.". Please, someone could review and upload if ok, thanks. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Request to review and upload librtr 0.6.3-2
Hi, Sorry my late. Peter Wienemann: > Dear Francisco, > > On 08.01.21 17:56, Francisco Vilmar Cardoso Ruviaro wrote: >> On 1/8/21 9:23 AM, Raphael Hertzog wrote: >>> He also pointed towards a possible upstream fix. Do you want to look into >>> backporting this? >>> >> I tried to get the latest version (0.7.0+git20201012.93724e4), applied >> the patch >> https://github.com/rtrlib/rtrlib/pull/260/commits/f81b70bf03a52b2e25f7154062c538dc050b3571 >> >> >> yet the bug continues. >> Unfortunately I was not successful. > > along with the mentioned patch you also have to add "pkg-config" to the > build deps. Have you considered this for your test? > That's right Peter, pkg-config was missing, thanks! I think librtr[1] is now ready for review and upload. [1] https://salsa.debian.org/pkg-security-team/librtr Best regards. -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Request to review and upload librtr 0.6.3-2
Hello Raphael, On 1/8/21 9:23 AM, Raphael Hertzog wrote: Hi, On Thu, 24 Dec 2020, Francisco Vilmar Cardoso Ruviaro wrote: I fixed an RC bug [0] in librtr [1]. Please, review and upload. Adrian Bunk pointed out that your fix is clearly incorrect. Can you at least revert your change please ?It would be nice if you tried to Sure, it's done. understand your changes before you are doing them. A symbol that disappears is a big deal because it breaks users of the library that are using this symbol. So it was relatively evident that the correct fix was not to acknowledge the disparition of the symbol (at least not without an explanation of why it's not important). Thanks Raphael, I need to be more careful and pay attention before any change, you're right, I need to understand better. He also pointed towards a possible upstream fix. Do you want to look into backporting this? I tried to get the latest version (0.7.0+git20201012.93724e4), applied the patch https://github.com/rtrlib/rtrlib/pull/260/commits/f81b70bf03a52b2e25f7154062c538dc050b3571 yet the bug continues. Unfortunately I was not successful. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Request to review and upload librtr 0.6.3-2
Hello Team, I fixed an RC bug [0] in librtr [1]. Please, review and upload. [0] https://bugs.debian.org/975174 [1] https://salsa.debian.org/pkg-security-team/librtr Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Help needed with plaso/dfvfs and their dependencies
Hi Raphaël, Raphael Hertzog: Hello, On Thu, 10 Dec 2020, Francisco Vilmar Cardoso Ruviaro wrote: Thanks for the clarification, this occurred because I downloaded another file that does not contain the bundled libraries [1]. Unlike the file you used [2]. [1] https://github.com/libyal/libluksde/archive/20200205.tar.gz [2] https://github.com/libyal/libluksde/releases/download/20200205/libluksde-experimental-20200205.tar.gz Do you think it is valid to package these auxiliary and support libraries? If they were used by other projects, yes. But here those libraries are made by the same author and for his own project only. Given the large number of libraries, it would only add busy work for no gain so I'd rather not package them separately. To be honest, many of those libraries smell the NIH syndrome[1] and should not exist in the first place IMO. Cheers, [1] https://en.wikipedia.org/wiki/Not_invented_here I hastened and created the libcerror project [1], sorry. Could you please delete it? [1] https://salsa.debian.org/pkg-security-team/libcerror Thanks, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Request to review and upload sleuthkit 4.10.1+dfsg-1~exp1
Hi Raphaël, Raphael Hertzog: Hi, On Sat, 19 Dec 2020, Francisco Vilmar Cardoso Ruviaro wrote: Dear security tools team, I prepared a new version of sleuthkit [1], release 4.10.1+dfsg. The version 4.10.1+dfsg introducing the ABI change (SONAME bump), /usr/lib/*/libtsk.so.19.1.2 > /usr/lib/*/libtsk.so.19.1.3. It's not a SONAME bump. The SONAME is unchanged and is libtsk.so.19. Thus there's no ABI change. My mistake, thanks for clarifying. Did you target experimental in the changelog because you thought it would require coordination with the release team? That's right, I thought it would be a transition. If it is satisfactory, please review and upload. Uploaded to unstable. Thanks a lot! -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Request to review and upload sleuthkit 4.10.1+dfsg-1~exp1
Dear security tools team, I prepared a new version of sleuthkit [1], release 4.10.1+dfsg. The version 4.10.1+dfsg introducing the ABI change (SONAME bump), /usr/lib/*/libtsk.so.19.1.2 > /usr/lib/*/libtsk.so.19.1.3. Analyzing 'reverse-depends -b src:sleuthkit' output, we have: Reverse-Build-Depends-Indep * autopsy (for sleuthkit) Reverse-Build-Depends * libguestfs(for sleuthkit) * libguestfs(for libtsk-dev) * pytsk (for libtsk-dev) I have locally rebuilt the reversed dependencies on amd64, and everything went well. If it is satisfactory, please review and upload. [1] https://salsa.debian.org/pkg-security-team/sleuthkit Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Help needed with plaso/dfvfs and their dependencies
Hi, On 11/30/20 11:17 AM, Raphael Hertzog wrote: Hello, I wanted to help a little bit to fix #971311 & #971308 related to the deprecation of PyCrypto but I have opened a can of worms. We need to package new upstream releases of dfvfs and plaso to fix those (and other RC bugs like #971149). But the new dfvfs requires 4 new packages: * python3-libfsext: https://github.com/libyal/libfsext * python3-libfshfs: https://github.com/libyal/libfshfs * python3-libfsxfs: https://github.com/libyal/libfsxfs I raised some requirements for packaging libluksde, * python3-libluksde: https://github.com/libyal/libluksde I worked on libcerror, if it is satisfactory, please review and upload, thanks! 1- https://github.com/libyal/libcerror (ITP: #976153) The project is already in the team repository: <https://salsa.debian.org/pkg-security-team/libcerror> If you can, enable CI please, I'm not allowed to do that, thanks. We need to package these dependencies as well: 2- https://github.com/libyal/libcnotify (depends on libcerror) 3- https://github.com/libyal/libclocale (depends on libcerror) 4- https://github.com/libyal/libcsplit (depends on libcerror) 5- https://github.com/libyal/libfguid (depends on libcerror) 6- https://github.com/libyal/libfcrypto (depends on libcerror) 7- https://github.com/libyal/libcdatetime (depends on libcerror) 8.a- https://github.com/libyal/libcthreads (depends on libcerror) 8.b- https://github.com/libyal/libcdata (depends on libcerror and libcthreads) 8.c- https://github.com/libyal/libfcache (depends on libcerror, libcthreads and libcdata) 9- https://github.com/libyal/libfdata (depends on libcerror, libcthreads, libcdata, libcnotify and libfcache) + https://github.com/libyal/libuna (depends on libcerror, libcdatetime, libclocale, libcnotify and libcfile) + https://github.com/libyal/libcfile (depends on libcerror, libclocale, libcnotify and libuna) + https://github.com/libyal/libcpath (depends on libcerror, libclocale, libcsplit and libuna) + https://github.com/libyal/libhmac (depends on libcerror, libclocale, libcnotify, libcsplit, libuna, libcfile and libcpath) The new plaso and dfvfs also bumped the minimal version of many dependencies that we should update too. It would be nice if someone could help here. I'll happily sponsor uploads if needed. Regards, Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 OpenPGP_signature Description: OpenPGP digital signature
Re: Request to review and upload libvhdi_20201018-1
Hello team, We talked to libvhdi upstream, in short, soname bump won't happen yet and he says "Checking with git whatchanged -p include/libvhdi.h.in I don't see any mayor API (and therefore ABI) changes in the last ~4 years; a couple of functions added and a couple of non-functional write functions were removed.". I have locally rebuilt the reversed dependencies (pytsk and sleuthkit) on amd64, and everything was built correctly, both in testing and in unstable. Below the output of the reversed dependencies: $reverse-depends src:libvhdi Reverse-Depends * libtsk19 (for libvhdi1) * python3-dfvfs (for python3-libvhdi) * python3-plaso (for python3-libvhdi) * python3-tsk (for libvhdi1) * sleuthkit (for libvhdi1) $reverse-depends -b src:libvhdi Reverse-Build-Depends * dfvfs (for python3-libvhdi) * plaso (for python3-libvhdi) * pytsk (for libvhdi-dev) * sleuthkit (for libvhdi-dev) Samuel, would you like me to request a transition slot for libvhdi? Best regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
OSDFCon 2020
Hello team, I take the opportunity to publicize the 11th Annual Open Source Digital Forensics Conference (OSDFCon), will be entirely virtual and will take place on November 18th, All details can be found at https://www.osdfcon.org. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to join the team
Hi Raphaël, Raphael Hertzog: > Hello Francisco, > > On Fri, 23 Oct 2020, Francisco Vilmar Cardoso Ruviaro wrote: >> having talked to Samuel Henrique, he has been my mentor and helped me >> introduce >> some packages to the team (bruteforce-wallet and stegcracker), so I would >> like >> to join the team to help in any way possible, >> >> if necessary, my salsa username is fvcr. > > You have been added to the team. Welcome! thanks a lot. > > You have the developer profile so you can contribute to existing projects > but you will still need our help to create a new gitlab project. > > Regards, > Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to review and upload libvhdi_20201018-1
Hi Samuel, Samuel Henrique: > FTR, Francisco correctly pointed out to me that upstream has not bumped > SONAME. > This means we have an issue at hand here, upstream removed interfaces > and should have bumped its API, we as the Debian maintainers can > introduce a "distro specific" new version (do the bump ourselves) but > that is not recommended and should only be the last resort[0]. > > Our ideal way forward here is contacting upstream, exposing the issue > and asking for a new release with the correct bump, especially since > this is likely to be an oversight by them. > > Can you open an issue on their issue tracker? sure, it's open: https://github.com/libyal/libvhdi/issues/15 > >> For reference: >> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > An extra reference which is very on point to this issue: > https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi > https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#upstreamconcerns > > [0] I can see one argument being made that we could avoid the distro > bump even by rebuilding the rdeps (just like a transition) but without > the bump, thus basically "hiding" the backwards compatibility > breakage, the risk here being that things built outside our official > repos might inadvertently break when linked against the new package. > In the end, if upstream does not provide a new release with a bump, we > will have to evaluate which will be the alternative with less > downsides. > > Regards, > > Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to review and upload libfsntfs_20200921-1
Hi Gianfranco, Gianfranco Costamagna: > done! thanks a lot. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to review and upload dfdatetime_20200824-1
Hi Gianfranco, Gianfranco Costamagna: > in the meanwhile I sponsored it :) thanks a lot. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Re: Request to review and upload dfdatetime_20200824-1
Hi Samuel, Samuel Henrique: > Hello Team, > > On Wed, 21 Oct 2020 at 13:31, Gianfranco Costamagna > wrote: >> >> in the meanwhile I sponsored it :) > > Thanks GIanfranco :) > >> Il mercoledì 21 ottobre 2020, 09:55:09 CEST, Raphael Hertzog >> ha scritto: >> I'm fine with this. I would however highly suggest Francisco to sign his >> commits so that anyone can look back at his history of signed commits and >> make his own judgment on his work. > > Good call, > >> If you are wondering seriously about granting him DD right, then why >> isn't Francisco a member of pkg-security yet ? He should be able to push >> his signed commits and you can review that. > > I have asked him to apply to the team, I don' t know if he did but I sorry, I forgot to ask to join the team. I will request. > also don't have permission to change members rights in the scope of > the team, only of the packages, so I'm currently giving him temporary > permissions on the packages he's working on. > Francisco, can you ask to join the team through Salsa? I didn't find how to ask directly at https://salsa.debian.org/pkg-security-team, I searched the menu on the left, I went through all the options I found, searched in Group overview (details and activity), Issues (list, board, labels and milestones) and Members, however I sent the request for list. > > Thanks, > Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Request to join the team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear security tools team, having talked to Samuel Henrique, he has been my mentor and helped me introduce some packages to the team (bruteforce-wallet and stegcracker), so I would like to join the team to help in any way possible, if necessary, my salsa username is fvcr. Regards, - -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00 -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEG4z2Vu87hEcvSPDngvv3BgsvfQAFAl+TVMgACgkQgvv3Bgsv fQDcng/+JdtCoxQqgHbteIRQ/WR0SyrhwKdMJMzmpWARTuMeWqDUjqBN+EbJ6+ej IDv1Xo/ebxWGjMAQ7f/L+ER8SZHO6P9yDu8altpYc7MPhaBHqUnjv89dKH0BcCtL WvMPSZ8VIL/R3PiquWHn5Ko2tqSSi6ADEYdFnk0pTPf9myrLRXW+2UBfF8JQGVO1 +0NvfFGylWtX/gt6TO5hJzibyUYqE3a6EsX1k4vIW3tOiiLr6AQZs8GrEgT3shad CfEW94ydn1cvCxS593ewTi889P1jW7ISw+nb/uxJ20AK+jgp1nFqxFlzAIZAZjpi K/fhF/j+PBCfwSzFWcpkPzEOD/zNOuBs2GiU8hCYbXck7+4vEhYTpm1wD+Lt2tY/ 06ZzLy8OHBuw5ODEn0Tq/A1Z5jMkcm+WJvYksrPXeFkMNW8zL7uuGxMJ1/B3jSzq lfpyc6RP1LGeXR9V2wWl4hS41jsA3Sn1IEyYATiQNit27UuXXwiyHuEyK8lSyHJo QihDzorX5YSQdTB1CM6PEoRG2YTpLB7oEwRuzix4QwOsGauTZ/CydDSc3U/0JW2P MFn5KReHYTsvABSR1DiAaVLeWFaZlG1cuwu6yfervby8zAtpvDERMkklcXfndFGF xw7kpzoC81czTbM16ACp/TAhyCDocXLIlsvSDSEtD64JN8P/Sfc= =ms9q -END PGP SIGNATURE-
Request to review and upload libvhdi_20201018-1
Dear security tools team, I prepared a new version of libvhdi, release 20201018. I am not allowed to push in official repository, so the changes are at: https://salsa.debian.org/fvcr/libvhdi if it is satisfactory, please review and upload. Regards, -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Request to review and upload libfsntfs_20200921-1
Dear security tools team, I prepared a new version of libfsntfs, release 20200921. I am not allowed to push in official repository, so the changes are at: https://salsa.debian.org/fvcr/libfsntfs if it is satisfactory, please review and upload. Regards -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
Request to review and upload dfdatetime_20200824-1
Dear security tools team, I prepared a new version of dfdatetime, release 20200824. I am not allowed to push in official repository, so the changes are at: https://salsa.debian.org/fvcr/dfdatetime if it is satisfactory, please review and upload. Thanks! -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
help with sleuthkit symbols
Hi team, I tried to generate symbols for libtsk19 from sleuthkit 4.9.0, the changes are in "fvcr/libtsk19" branch, I found lintian symbols-file-contains-current-version-with-debian-revision and I didn't know how to solve it. I generated the symbols, after the package was built, I did it like this: $ dpkg-deb -x libtsk19_4.9.0+dfsg-1_amd64.deb /tmp/libtsk19 $ dpkg-gensymbols -v4.9.0 -plibtsk19 -P/tmp/libtsk19 -O/tmp/libtsk19.symbols1 $ sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' libtsk19.symbols1 | c++filt > libtsk19.symbols Please can someone explain to me how to generate the symbols correctly? I still have another lintian, after Bump to DH 13, FTBFS occurred, to solve this i added usr/lib/*/libtsk.la in debian/libtsk19.install dh_missing: warning: usr/lib/x86_64-linux-gnu/libtsk.la exists in debian/tmp but is not installed to anywhere however, another lintian arises non-empty-dependency_libs-in-la-file, I didn't know that [1], so I kept DH level 12. [1]: https://wiki.debian.org/ReleaseGoals/LAFileRemoval Regards. -- Francisco Vilmar Cardoso Ruviaro 4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00
