Re: pkg-security-tools sprint in DebCamp
Hi Charles, On 2024-07-09 14:48:21, Carlos Henrique Lima Melara wrote: In the end of the month we will have DebCamp and DebConf happening and I'd like to organize a team sprint during DebCamp. DebCamp will take place from Sunday July 21st to Saturday July 27th, but I'll only arrive on 23rd. So, my first question is if anyone from the team will arrive for DebCamp. The second is for people not attending this year, I'd love if you could join remotely so we can get our packages ready for trixie! thank you very much for your initiative. Unfortunately I will not be able to make it to DebCamp this year, neither in person nor remotely. Best regards, Peter
Re: New DD applications from the team: wiene and sge
Hi Samuel, On 2024-06-08 14:30:40, Samuel Henrique wrote: I am excited to let you know that Peter and me completed our exams successfully and have been granted DD access this morning. Awesome! Congratulations to you both! thank you very much! My appreciation goes to everybody I worked with during the last few years, especially Samuel, for their support and their highly valuable feedback to my work. Appreciate it, you and Peter made it easy for me as a reviewer :) I can only underline what Sven wrote. I am deeply grateful for all the support and advice I received. I am looking forward to extending contributing to the team and the Debian Project in its entirety. Also consider attending a DebConf or MiniDebConf near you. DebConf25 will be in France and the project can cover some or all of your costs through the bursary program (applications for DC24 are closed already). If we ever get enough people and a plan, we can even organize an in-person BSP for the team (again, the project can cover some/all of the costs). As few as 4/5 people should be enough to organize something as long as we have a plan of things to work on. I attended the MiniDebConf in Berlin three weeks ago and I really enjoyed it. I am looking forward to more in-person Debian events. :-) Best regards Peter
Re: Two bug fixes for ncrack
Dear Sven, On 2024-01-06 10:58:41 +0100, Sven Geuer wrote: On Fri, 2024-01-05 at 20:59 +, Peter Wienemann wrote: The suggested fix for #1048666 works but it is not particularly nice. If someone knows a smarter way how to address this issue, I am eager to learn about it. Instead of extending d/rules I propose to drop the offending files in advance by a patch. This way there is not need to save and restore them. Refer to [1] as an example. You can create such a patch easily via 'dquilt shell'. See [2] and [3] if you are not familiar with it [1] https://salsa.debian.org/debian-remote-team/tightvnc/-/blob/debian/master/debian/patches/remove-upstream-build-system.patch?ref_type=heads [2] https://www.debian.org/doc/manuals/debmake-doc/ch03.en.html#quilt-setup [3] https://manpages.debian.org/bookworm/quilt/quilt.1.en.html#shell many thanks for your suggestion and the illustrative example. Trying to use a patch to remove and restore the clobbered files has not come to my mind so far. What I like about your approach is that it is more straightforward. What makes me a bit hesitant in this particular case is the size of the needed patch to accomplish this: It is tens of thousands of lines. So at least in terms of diff size it is more invasive. Considering both options I do not have a clear preference. But maybe others do. :-) On 2024-01-06 11:28:30 +0100, Sven Geuer wrote: > An additional approach worth to explore is to patch upstream's > Makefile.in files to do the clean job correctly. Some parts are already > available as distclean targets. I think this approach can only solve issues caused by an incomplete clean-up of build remnants. However in the given case one needs to restore the original state of files modified during the build. Therefore I fear that this second approach does not solve the problem at hand. Thanks again for your input. It was very instructive. Best regards, Peter
Two bug fixes for ncrack
Dear security tools packaging team, I pushed two commits to the ncrack repository [0] fixing two bugs: https://bugs.debian.org/1058286 https://bugs.debian.org/1048666 #1058286 is an RC bug. The suggested fix for #1048666 works but it is not particularly nice. If someone knows a smarter way how to address this issue, I am eager to learn about it. Best regards, Peter [0] https://salsa.debian.org/pkg-security-team/ncrack
RFS: New upstream release for ssldump (version 1.8)
Dear security tools packaging team, I have prepared the Debian packaging of a new upstream release of ssldump (version 1.8): https://salsa.debian.org/wiene/ssldump This release introduces a cmake based build system which fixes #1049319 as a by-product. It would be great if someone could review my changes and - provided they look reasonable - push the changes to https://salsa.debian.org/pkg-security-team/ssldump and upload the new version. Many thanks and best regards, Peter
Re: Bug#1032462: ITA: argon2 -- memory-hard hashing function
Hi Sven, On 24.10.23 01:13, Sven Geuer wrote: Thanks for pointing this out. However, I am unsure if lintian would still complain in regards to argon2 (and also dnstwist) as the package is not a new one anymore. The explanation in [1] cleary states This package appears to be the first packaging of a new upstream software package (there is only one changelog entry and the Debian revision is 1) and uses a date-based versioning scheme such as MMDD-1. and upstream kept using the MMDD versioning scheme since the beginning in 2015 (they might change their mind, though). as you suspect the Linitian tag is only emitted if the number of changelog entries is one. The reason is that it is too late to switch to the suggested versioning scheme after the first upload. Once an upload with a date-based versioning scheme has been done, an epoch likely needs to be introduced in case upstream switches to a conventional versioning scheme. Therefore this Lintian hint become pointless after the first upload. Still the reasoning to avoid prefix-less date-based versioning schemes remains valid. Best regards, Peter
Re: Bug#1032462: ITA: argon2 -- memory-hard hashing function
Dear Sven, On 23.10.23 17:19, Sven Geuer wrote: I would prefer to remove the 0~ prefix from the package version, resulting in an upcoming version of 20190702+dfsg-4 instead of 0~20190702+dfsg-4. This would align the version in Debian to other distros, see [1] for details. Are there arguments to not change the versioning in this way? [1] https://repology.org/project/argon2/versions I see the same issue for dnstwist [0]. Still there is a good reason to keep the present Debian versioning as it is - see the description of the Lintian tag "new-package-uses-date-based-version-number" [1] for an explanation. Best regards, Peter [0] https://repology.org/project/dnstwist/versions [1] https://salsa.debian.org/lintian/lintian/-/blob/d44a4d1a4a053b39ca2acbfa0c67ac4b5e04df59/tags/n/new-package-uses-date-based-version-number.tag
Extension of permissions to push to dnstwist repository
Dear Samuel, dear security tools team, On 03.05.20 15:38, Samuel Henrique wrote: Peter, I noticed you are the maintainer of the package and is also a DM, so I gave you permission to the repository, maintainers should be able to push to their packages' repos. I forgot to mention, this permissions will expire at the end of 2021, so if you're not a DD by that time just ask someone to bump the expiration for you. since the end of 2021 is getting close, I would like to ask someone with the necessary rights to extend my permissions to push changes to the dnstwist repository [0]. Many thanks, Peter [0] https://salsa.debian.org/pkg-security-team/dnstwist
Re: Help with mdk4 FTBFS when building in parallel
Hi Samuel, On 29.08.21 18:06, Samuel Henrique wrote: I've tried to build around 10 times with --max-parallel=12 (causes -j12) and I got around 2 builds to succeed. This might be a red herring, but are you running sbuild with the performance tweaks explained in the wiki[0], by any chance? I'm using all of them. yes, I am also using all of them although my tmpfs setup follows the guidance in an older version of the sbuild wiki page (see first alternative on [0]). Best regards, Peter [0] https://wiki.debian.org/sbuild?rev=184#sbuild_overlays_in_tmpfs
Re: Help with mdk4 FTBFS when building in parallel
Hi Samuel, On 29.08.21 15:41, Samuel Henrique wrote: I need help investigating why mdk4 randomly fails to build when in parallel, I've been through the build log and couldn't spot anything. The failure rate with -j16 is around 85%, I couldn't reproduce the issue with -j1. I also can't reproduce the issue directly in the upstream code with make -j16, this just happens to me when under sbuild (it could have something to do with the IO performance of schroot + eatmydata + tmpfs). I've just tried to reproduce the issue with -j12 using sbuild. Out of 8 test runs none failed. Which approximate failure rate do you observe with -j12? Best regards, Peter
Re: Request to review and upload librtr 0.6.3-2
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? Best regards, Peter
RFS: New dnstwist upstream version and bug fix (was: Test suite issue fixed for dnstwist)
Dear security tools team, On 11.04.20 15:11, Peter Wienemann wrote: > could someone please review the changes in > > https://salsa.debian.org/wiene-guest/dnstwist > > and - provided they look OK - push the changes to the corresponding > repository in the team area and upload. > > This fixes an issue in the test suite which blocks migration to testing. in the meantime upstream released a new version. I added the new upstream version and some entailed modifications as well as a fix for #958735. I am looking forward to a review/upload. Peter
Test suite issue fixed for dnstwist
Hi, could someone please review the changes in https://salsa.debian.org/wiene-guest/dnstwist and - provided they look OK - push the changes to the corresponding repository in the team area and upload. This fixes an issue in the test suite which blocks migration to testing. Thanks, Peter
Re: RFS: dnstwist
Hi SZ, On 25.03.20 04:39, SZ Lin (林上智) wrote: > Thanks for your contribution, I've created this repository and import your > commits in the pkg-security team. > > [1] https://salsa.debian.org/pkg-security-team/dnstwist [...] > I didn't see any issues, but one thing to be aware of that someone > also wrote a manpage of dnstwist and sent the PR to the upstream. > > [2] https://github.com/elceef/dnstwist/pull/91/files thank you for your review, the repository creation and the upload. Concerning the manpage, I will discard the present one as soon as the mentioned PR has been merged. Do I have permission to push updates to the newly created repository? Peter
RFS: dnstwist
Dear DDs, I prepared packaging for the domain name permutation engine "dnstwist" (ITP bug #948237). The git repository is currently available at https://salsa.debian.org/wiene-guest/dnstwist It would be great if someone could review the code, provide feedback and - once everything looks fine - transfer the repository to the security tools team area and upload the package. Thanks, Peter
Re: RFS: arp-scan (fix #910140 and more changes)
Hi Thiago, On 31.10.19 16:18, Thiago Marques wrote: > https://salsa.debian.org/pkg-security-team/arp-scan/tree/arp-scan_1.9.5-2 > [...] > The cowbuilder is working perfectly but CI Test on Salsa didn't work. I cannot help with the upload (due to insufficient rights) but I looked into the build failure claimed by the CI system and it seems that this is caused by a glitch of the CI system rather than a problem with the code. I just re-ran the CI pipeline (on a fork) and all tests passed this time. Peter
