Re: Request to join the team
Hello Guilherme, > My name is Guilherme Xavier, I've been a Debian user for over 15 years and > for a few years I've been studying a lot about packaging in Debian. I've done > some QA work and now I'm looking to bring some new packages to Debian more > precisely related to security. Awesome, welcome to the team, > I am packaging the "Seclists" from Kali (https://pkg.kali.org/pkg/seclists) > for Debian and I would like to be part of the team if possible. I am being > mentored during the packaging by Samuel Henrique who has given me many tips > during the process. I also request the creation of the package repository in > salsa. I hope I can help the team. I have created the repo and gave you Salsa's maintainer role: https://salsa.debian.org/pkg-security-team/seclists Can you also apply to join the org on Salsa? https://salsa.debian.org/pkg-security-team There should be a button for it, otherwise you're gonna have to ask Raphaël to add you. I will review seclists in the next couple of days, right after I review pocsuite3. Thank you for your contributions! -- Samuel Henrique
Re: Request for join the team
Hello Tian, Sorry for the delay in the reply, I have created a repo under the team's org and gave you permission, you can push start pushing your changes there: https://salsa.debian.org/pkg-security-team/pocsuite3 The packaging seems to be in a good shape, I have a few suggestions/questions: 1) d/copyright: You can remove the comments on lines 7-8 and also make the first Files entry (on line 10) shorter by stating "Files: *", this means that anything not called out in the other copyright entries below will fall into the wildcard one. 2) pocsuite3/thirdparty/: There seems to be a few python libraries vendored in that folder, I'm not sure if they're patched or just plain vendored. Generally speaking we can't use them and should instead rely on their packaged versions on Debian, eg.: make the package depend on "python3-prettytable" instead of using the vendored version. This can also help by making d/copyright even simpler if you can remove it from the orig tarball (either with a repack or if you can provide a tarball without it, as upstream). Now, I understand that ansistrm, for example, is not packaged on Debian, and so It should be fine to keep this one as it is, but otherwise could you try to use the ones already packaged on Debian and make sure they are not shipped in a vendored manner for pocsuite3? You can keep them in the orig tarball if you'd like, and we can also discuss using vendored libs if you need them, please let me know if that's the case, and also let me know if you need help or would like more details about it. 3) pocsuite3/data/cacert.pem: I noticed this file contains both the public and private parts of the key, to initialize an http server on port 666 and wrap the socket with ssl. I believe this is fine (it's gonna be up to the ftp-master to confirm that it's ok), but I wonder if you thought about generating a self-signed cert at runtime[0] instead of reusing the same one for everyone? Note that you don't need to make this change, I'm just wondering if there's any pros and cons that I'm not considering since there's a chance you've already discussed this with other developers of pocsuite3. 4) flake8 + black: Just a suggestion here, not a blocker for having pocsuite3 on Debian; flake8 seems to detect a lot of small thing that you probably want to have it fixed, and black can automate some of those changes for you. None of them seem to really be causing any bugs, but having flake8 enforced at development stage will definitely spot an issue for you eventually. 5) docstrings: This is also just a suggestion and definitely not required for packaging pocsuite3 on Debian: I noticed some docstrings in the code are not in english, this is not a big deal since the code itself is in english and I could understand it without issues (at as far as I went, since I didn't read everything). I think it's a good idea to eventually translate them to english (you can keep both languages) to make it easier for others to contribute. But again, please take this as a suggestion for a low priority improvement. [0] Alternatively, it should also be possible to generate it at the install-time of the deb package with the pre/postinst maintainer scripts. Thank you for your contributions! -- Samuel Henrique
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: Request for join the team
Hello Tian, > I have fixed most of the problems in the latest upload. > pocsuite3_1.7.6-1 is now at https://mentors.debian.net/package/pocsuite3/. > Please let me know if there is any other mistakes I have to fix. > Thank you very much for your attention. Grand, did you manage to get a Salsa account? I've reviewed the upload to mentors but it would be better if we could do reviews based on git (you could also make use of salsa-ci to automatically build and detect some issues[0]). The package is failing to build for me due to 2 reasons: 1) Missing build dependencies: You will have to add python3-requests and python3-requests-toolbelt to fix this. I believe you might be building your package in a dirty environment, which contains other packages installed that could trick you into believing that the Build-Depends field is correct. For building packages I suggest using sbuild[1], this will ensure you get a clean environment for every build. 2) Unit tests are using the internet: Our policy states that a package should not use the internet during its build process[2], and our debhelper's python integration will automatically discover and run unit tests. In order to fix this you will have to disable the tests which require internet access, or disable all of the tests by overriding the dh_test with a noop[3]. [0] You can push a configuration like this https://salsa.debian.org/debian/mtr/-/blob/debian/master/debian/salsa-ci.yml and configure your repo to use it (Salsa's default is gitlab-ci.yml, you will need debian/salsa-ci.yml) [1] https://wiki.debian.org/sbuild [2] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules : 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. [3] https://sources.debian.org/src/ocrmypdf/10.3.1+dfsg-1/debian/rules/?hl=39#L39 Thank you for your work, and let me know if you need help getting a Salsa account or have questions about how to solve any issues. -- Samuel Henrique
Re: Intent to repackage Kali's bulk_extractor
Hello Jan, > However, pkg-security-team's "Kali-Debian-tracker-spreadsheet" states Oh, I had forgotten about that spreadsheet, I thought nobody was looking at it. I have to consider updating or removing it to avoid confusion with old data (last run was in 2019). If anybody reading this considers that spreadsheet[0] useful even with old data from 2019, let me know. It helped me get an overview of kali vs debian packages around that time but I stopped updating it, I'll dedicate some time to see if the script[1] still works. > the following Lintian errors regarding bulk_extractor: > > ``` > - 1 possible-gpl-code-linked-with-openssl > - 1 license-problem-json-evil I can see you already fixed these two issues with upstream, which is a really nice thing. I'll review your package during this weekend. Thanks a lot for your work and sorry for the late reply. [0] https://docs.google.com/spreadsheets/d/1muSrob3G1c7ZwHlxfDAho4qtdJ9pZNycCKT9kWyIJkw/edit#gid=1566900788 [1] it's generated by a somewhat poor bash script, so it's prone to issues all the way. -- Samuel Henrique
Re: Request for join the team
Hello Tian, > I’m Tian Qiao, a security researcher belongs to knownsec 404 team. Welcome, > I’ve packaged a new security related tools, and plan to put it into Debian > repo. Cool, I haven't yet checked the software itself but I can give you some feedback on the packaging, it looks like there's a few lintian findings you will have to get fixed before we can consider the package. The most important ones are of type "E/Error", but it's a good idea to try to fix all of them, you can see the list of findings under "Package has lintian errors" in the mentors page. We can help you fix them if you have questions, so give it a try and feel free to ask for help. Thanks, -- Samuel Henrique
Re: rsakeyfind - Request for review of autopkgtest addition
Hello Jan, Merged, I liked your solution and it's also gonna be very helpful to debug the aeskeyfind issue you found[0]. I'd like to point out one interesting thing from the MR, which I believe other from the team might also like to know: https://salsa.debian.org/pkg-security-team/rsakeyfind/-/merge_requests/2#note_242977 Apparently there's a race condition in doing: (command) & ps aux | grep command I'm not sure where exactly it comes from, but Jan mitigated that by adding a short sleep between the commands. [0] https://bugs.debian.org/989179 Thanks, -- Samuel Henrique
Re: rsakeyfind - Request for review of autopkgtest addition
Hello Jan, > I want to ask for a review of a recently created merge request > concerning the memory forensics software `rsakeyfind` [1]. > I added autopkgtests to check the correct functionality of the created > package. These include a smoke test to check its startup behaviour as > well as tests to verify the extraction of a 256-bit and a 2048-bit RSA > key from pre-generated, but sizewise tiny process memory dumps, which > contain key material generated either by Openssl or with the help of the > Python library pycryptodome [2]. This is a really nice contribution! > If you think, that I should add the helper scripts and/or the > documentation regarding the creation of those memory dumps also, please > let me know. I left a comment there related to this, I believe you will have to automate the generation of those dmp files because otherwise we have issues due to missing their source code. Thank you for your contributions! -- Samuel Henrique
Re: john - Request for review of merge request - Add autopkgtests
Hello Jan, > recently I submitted a merge request to add autopkgtests to the > hash-cracking software `john` [1]. > I want to kindly ask for a review and a merge of this addition, if it > fulfills the quality standards. Awesome, I just merged your MR. > Furthermore, I wonder, whether you took into consideration to package > the "jumbo"-version of `john` also, which contains helpful features for > the real world password-cracking use of `john` -- especially in a > forensics-context? In Kali this version is already packaged [2]. Would > you accept this version -- e.g. with a package-name like `john-jumbo` or > `jtr-jumbo` -- as an addition? We had a brief discussion about this back in January, the conclusion is that we want to have the jumbo version packaged but only after bullseye's release. Check out this thread for more details: https://lists.debian.org/debian-security-tools/2021/01/msg00018.html Thanks for your contribution :) -- Samuel Henrique
Re: Scalpel - Request for review of merge request - Closes #980064
Hello Jan, > I am kindly asking for a review of this merge request which closes > #980064. Thanks already in advance. Thank you for working on this, I've left a comment about a small changelog issue. I don't think we can upload this change to unstable due to the freeze, but we are good to merge and leave it in debian/master, to be uploaded as soon as the freeze is gone. Cheers, -- Samuel Henrique
Re: Request for review/upload of regripper 3.0-1
Hello Arnaud, I believe you mentioned you were interested in reviewing this upload, do you still have plans to do it? I can help but I wanted to avoid duplication of work. Thanks, -- Samuel Henrique
Re: Introductory Message - Contributing to Debian Forensics Environment
Hello Jan, Welcome to the team! Please feel free to reach out if you need any help/sponsor and also to bug me if it takes too long for you to get a reply, I try to prioritize helping people over working on my packages (as I believe it's more effective to unblock someone) but as you can see, it might take a few days. If you have a request pending a response for at least 2 weeks, please let me know and I'll prioritize it. I've sent you a private reply before, as I was busy, but now I've got enough time to catch up with the backlog, sorry for that. Regards, -- Samuel Henrique
Re: Membership removed from project proytunnel
Hello Sven, > Please re-assign me to the proxytunnel project. Done, I've set the new expiration date to be end of 2022. Regards, -- Samuel Henrique
Re: Request for review/upload of stegseek 0.5-1~exp1
Hello Francisco, > I'm looking for a sponsor for a new package, stegseek [1]. > > Please, could you review and upload it for the experimental? Uploaded, thanks for working on it :) Cheers, -- Samuel Henrique
Re: Last days before the soft freeze
Improved UDD query (with a commented time window filter): select bapase.source, bapase.upload_date, bapase.testing_version, bapase.rc_bugs from bapase, all_sources where bapase.source = all_sources.source and all_sources.maintainer_email = 'team+pkg-secur...@tracker.debian.org' and /*bapase.upload_date <= '2020-01-01'::date and bapase.upload_date >= '2018-01-01'::date and*/ bapase.unstable_version is not null group by all_sources.source, bapase.source, bapase.upload_date, bapase.testing_version, bapase.unstable_version, bapase.rc_bugs order by bapase.upload_date Slightly shortened result of query: source|upload_date|testing_version |rc| --|---||--| openscap-daemon |2018-07-25 20:50:30|0.1.10-3| 0| scap-security-guide |2018-07-26 19:07:41|0.1.39-2| 0| bdfproxy |2018-09-11 21:39:33|| 1| dsniff|2018-11-05 01:03:59|2.4b1+debian-29 | 1| statsprocessor|2019-07-08 17:09:37|0.11+git20160316-2 | 0| onesixtyone |2019-07-16 10:34:33|0.3.3~git20190328-2 | 0| doona |2019-08-03 13:34:17|1.0+git20190108-1 | 0| sandsifter|2019-08-05 07:09:50|1.04-1 | 0| python-darts.lib.utils.lru|2019-09-04 12:20:05|0.5-5 | 0| swatch|2019-09-15 23:24:13|3.2.4-3 | 0| dhcpig|2019-09-24 14:49:28|1.5-3 | 0| binwalk |2019-10-17 09:49:06|2.2.0+dfsg1-1 | 0| pyaff4|2019-10-20 16:35:34|0.27+really0.26.post6-1 | 1| python-vulndb |2019-11-17 08:42:15|0.1.3-2 | 0| arp-scan |2019-11-27 17:49:09|1.9.7-1 | 0| samdump2 |2019-11-28 17:21:29|3.0.0-7 | 0| nasty |2019-11-28 18:34:34|0.6-4 | 0| libewf|2019-12-03 16:21:14|20140807-2 | 1| unhide|2019-12-14 00:34:16|20130526-4 | 0| rekall|2019-12-26 14:40:17|1.7.2~rc1+git20190104+dfsg-2| 1| >> As usual, I'd be happy to sponsor any uploads, and we have about 2 >> days left for this work (for the packages that take 10 days to >> migrate). > I miscalculated it, we have until around this Friday for the uploads > to reach testing (if urgency set to medium and without regressions). I'm actually not being exactly correct on this again, so please refer to the official doc at: https://release.debian.org/bullseye/freeze_policy.html We can still upload "Only small, targeted fixes" up until at least 2021-03-12. Cheers, -- Samuel Henrique
Re: Intro + Re: Heads up: Bug#981055: O: john -- active password cracking tool
Hello Axel, > > I was about to send an email talking about this, I started working on > > it myself to get an idea of how much work will be needed and I totally > > gave up trying to get it for bullseye (especially considering the > > deadline for NEW is tomorrow). > > Would the jumbo patch have to go through NEW? I only see john, > john-data and john-dbgsym in Kali (i.e. same package names as in > Debian). Oh noes, that was a brainfart, the actual deadline is 2021-02-12 (only small changes allowed after this date), still not enough time though. Cheers, -- Samuel Henrique
Re: ed2k-hash (0.4.0+ds-4) ready for upload
Hello Sven, > According to https://ftp-master.debian.org/dm.txt I am still missing DM > permissions for ed2k-hash. Would you please check this? I had forgotten about it, it's done now, thanks for the heads up! Cheers, -- Samuel Henrique
Re: Intro + Re: Heads up: Bug#981055: O: john -- active password cracking tool
Hello Axel, > sorry for the late reply. No worries, it wasn't late and I don't mind if you take your time :) > Will hopefully finish that part this night and upload. Didn't find > much time for packaging the past few days. Awesome, > I though do _not_ intent to import 1.9.0 or the Jumbo patch before > Bullseye. There are quite some reverse dependencies to john and I do > not want to break any of them at this stage of the freeze as I don't > know that much about the Jumbo patch. I just know that Kali already > has it (and 1.9.0) packaged. > > I also have not much of an idea how well the licenses of the Jumbo > patch have been reviewed for inclusion in Debian, which could pose > another source for RC bugs. I was about to send an email talking about this, I started working on it myself to get an idea of how much work will be needed and I totally gave up trying to get it for bullseye (especially considering the deadline for NEW is tomorrow). > * Check how much the packaging from Kali and Debian differs. > * Check how well debian/copyright was maintained in Kali for the jumbo > patch part. > * Eventually merge the two packagings and upload the result to > Experimental (at least if we're still in the freeze then). I agree with your plan of action. Here are a few notes I got from my quick look at it: * d/rules is still complex and quite different, so reviewing them will take a good chunk of time. * d/patches does not change much, it will be easier to sync from kali (assuming we won't need more patches on top of it). * d/copyright from kali looks good but there's still about 4 hours of work needed to finish it (as debmake -k shows me). I have started it but it's a slow process because it's the most boring thing ever. So far I haven't spotted any license incompatibility but I'm afraid there might be some binaries on the sources (haven't confirmed it yet). * d/watch from kali is pointing to github, I changed my local version to keep using upstream's website as the signatures are only provided there, it was an easy change. * testing will have to be extensive, considering the scope of the changes and how john has all sorts of tweaks for different architectures > In other news: I just uploaded plaso with the last RC bug fixed. Great, thanks for joining the team :) -- Samuel Henrique
LinPEAS - Linux Privilege Escalation Awesome Script
Hello team, I just found out about this interesting project, haven't tried yet and shellcheck complains about a bunch of stuff but it looks like an interesting project: https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS This "privilege-escalation-awesome-scripts-suite" also provides a script for Windows but I guess there's not much use for us (only if we want to package as a payload). Cheers, -- Samuel Henrique
Re: Last days before the soft freeze
For future reference, here's an UDD[0] query to sort our packages by the last_upload date: /* pkg-sec old uploads */ select all_sources.source, MAX(upload_history.date::date) as last_upload from all_sources, upload_history where upload_history.source = all_sources.source and all_sources.maintainer_email = 'team+pkg-secur...@tracker.debian.org' and all_sources.release = 'sid' group by all_sources.source order by last_upload These are the result up until 2019: crack2018-06-05 openscap-daemon2018-07-25 scap-security-guide2018-07-26 bdfproxy2018-09-11 dsniff2018-11-05 statsprocessor2019-07-08 onesixtyone2019-07-16 doona2019-08-03 sandsifter2019-08-05 python-darts.lib.utils.lru2019-09-04 inetsim2019-09-05 hashdeep2019-09-13 swatch2019-09-15 forensic-artifacts2019-09-19 dhcpig2019-09-24 binwalk2019-10-17 pyaff42019-10-20 reglookup2019-10-27 vinetto2019-11-12 python-vulndb2019-11-17 arp-scan2019-11-27 plaso2019-11-28 samdump22019-11-28 nasty2019-11-28 libewf2019-12-03 unhide2019-12-14 rekall2019-12-26 ext4magic2019-12-28 [0] https://wiki.debian.org/UltimateDebianDatabase/ -- Samuel Henrique
Re: Intro + Re: Heads up: Bug#981055: O: john -- active password cracking tool
Hello Axel, That's a nice introduction, welcome to the team :) If I understood correctly, you're working (or about to start working) on packaging the jumbo version of john, is that correct? I haven't looked deep into the kali packaging[0] of it yet so I don't have an idea of how much work it will be, so feel free to ask for help. Considering we have until around Friday to make it to bullseye, I can spend some extra time on it to make it happen (if it's feasible, of course). Cheers, [0] https://gitlab.com/kalilinux/packages/john -- Samuel Henrique
Re: Last days before the soft freeze
> My approach to it is currently to pick any package with the same > version in stable and testing and working on a new upload I have uploaded the last package now, the only one left with the same version as in stable is "crack", which Giovani is currently working on to solve an issue reported by blhc. > I'd like to take a look at any packages that are not shipping the latest > upstream version and see if it's sane to package it (talking about > small upstream changes here) and then take a look at any open bugs we > have. Alright, so I guess now it's the time to look at any open bugs and newer upstream releases. I was thinking about helping folks with john (getting the jumbo version in time), and packaging arpwitch[0]. > As usual, I'd be happy to sponsor any uploads, and we have about 2 > days left for this work (for the packages that take 10 days to > migrate). I miscalculated it, we have until around this Friday for the uploads to reach testing (if urgency set to medium and without regressions). Cheers, [0] https://github.com/verbnetworks/arpwitch -- Samuel Henrique
Re: ed2k-hash (0.4.0+ds-4) ready for upload
Hello Sven, > I prepared ed2k-hash (0.4.0+ds-4) on salsa [1] and added myself as > uploader. Great, I just sponsored it. There was a lintian warning which I solved, it was the "debian-watch-lacks-sourceforge-redirector". Can you check if your tooling is showing you that lintian for commit 093ad388f6f147b3b055849577ff3fb0c9a49281? There's no fault in missing lintian warnings, I just ask this to confirm that the tooling is working properly (as sometimes we might get weird behaviors). > Please review and upload the package or grant upload permissions to me > so that I can do the upload myself. I'll gladly give you DM permissions after the package arrives on unstable. Thanks for your work :) -- Samuel Henrique
Re: Last days before the soft freeze
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 arpon: skip-systemd-native-flag-missing-pre-depends: Lintian was throwing this warning so I added the "Pre-Depends" field as requested by it. Once again, thanks for your work :) -- Samuel Henrique
Last days before the soft freeze
Hello Team, As you know, we are close to the soft freeze for the bullseye release[0], so I started working on the packages that didn't have any uploads made after the last stable release (mid 2019). If you feel like looking for something to work on, I would be happy to have someone helping me tidying up our team's packages. My approach to it is currently to pick any package with the same version in stable and testing and working on a new upload, even if it's just to bump the usual stuff like debhelper and policy, most of the packages can benefit from a simple rebuild (which will use an updated tooling, like a newer compiler). For pretty much all of the ones I worked on there was more to it though, like the famous "Rules-Require-Root"[1] field or even a missing upstream signature, so I can say it's not that boring. After taking a look at the packages with the old last-upload date, I'd like to take a look at any packages that are not shipping the latest upstream version and see if it's sane to package it (talking about small upstream changes here) and then take a look at any open bugs we have. As usual, I'd be happy to sponsor any uploads, and we have about 2 days left for this work (for the packages that take 10 days to migrate). Cheers, [0] https://release.debian.org/bullseye/freeze_policy.html [1] For which in one case I could patch upstream to enable a "rootless build" -- Samuel Henrique
Re: libpff_20180714-3 is ready for upload
Hello Aleksey, > [1] https://salsa.debian.org/pkg-security-team/libpff Awesome, uploaded, I will give you DM permissions once the package hits the archive, Thanks for your work! -- Samuel Henrique
Re: libpff_20180714-3 is ready for upload
Hello Aleksey, > Or, alternatively, you can grant me DM rights for libpff upload. I'm happy to do that, although I don't think I can give you DM rights for a package you're not the maintainer/uploader, but even if it's possible, what do you think about adding yourself as an Uploader? I can see the last 3 uploads were done by you (since 2018) and you have been doing a good amount of work there. Cheers :) -- Samuel Henrique
Re: rhash_1.4.1-1 is ready for upload
Hello Aleksey, > Could you, please, give me DM upload rights for rhash? Done! Thanks for your work! It should take a few minutes for the permissions to take effect, you will receive an email once it's done -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
Hello, On Tue, 15 Dec 2020 at 08:40, Raphael Hertzog wrote: > If we don't have packages affected by the symbol removal (which looks like > to be the case given that all packages are still building) then we don't > need to bump the SONAME and we don't need any transition. Feel free to > upload to unstable right away. > > We don't have to care about programs manually compiled by the user, those > are outside of our control. And honestly, we're not speaking of a popular > library here so... Agreed and uploaded! -- Samuel Henrique
Re: Intro and Intent to Package
Hello Christian, On Tue, 1 Dec 2020 at 15:33, Christian Blichmann wrote: > Thanks for checking in with me. I still want to package this, but > other work items have prevented me from continuing with this. I'll see > that I squeeze some time in this week for this. > That' s great to hear, I don't really remember how much is still missing to be done as I know you pushed more changes. I take it that since you still have intent, and packaging is on salsa, the rest of the team is free to help on any changes needed and hopefully we can make it reach bullseye :) Cheers, -- Samuel Henrique
Re: tomb (2.8.1+dfsg1-1~bpo10+1) ready for upload
Hello Sven, I prepared tomb (2.8.1+dfsg1-1~bpo10+1) for buster-backports [1]. > Awesome, > Unfortunately my request to the backports team to get uploads > permissions for tomb has not been answered yet. Yeah, the backports ACL requests usually takes some days to be acked. Uploaded, have a good weekend :) -- Samuel Henrique
Re: Switch to KGB
Thanks for that Raphaël and Unit193 :) -- Samuel Henrique
Re: Intro and Intent to Package
Hello Christian, I hope you are doing well, I'm sending a ping on this thread as we are getting closer to the bullseye freeze, but there's still time to get this package on it. Regards, -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
Hello all, 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.". > For reference, this was the ticket: https://github.com/libyal/libvhdi/issues/15 > Samuel, would you like me to request a transition slot for libvhdi > I thought about this, as we have the option of performing the upload without a transition. My conclusion is that we should get the opinion of the release team on this, to lean on the safer side, so my suggestion is to: Upload what we have now to experimental; Create a bug for the release team explaining the issue and asking if they want us to do a transition or if just the binNMUs are fine. Views from the rest of the team are welcome :) Regards, -- Samuel Henrique
Re: DD Ping: Review of Tomb for CVE-2020-28638
Hello Sven, I prepared fixed versions of tomb for unstable [1], 2.7+dfsg2-2, and > buster-backports [2], 2.7+dfsg2-2~bpo10+1. Please review these. I added > myself as uploader, so feel free to provide upload permissions to me. > Nice, upload sponsored and I just sent the dcut command to give you upload permissions. If you haven't yet asked to be added to the backports ACL, you can do so by following this link's instructions: https://backports.debian.org/Contribute/ In the meantime, I'm happy to sponsor the backports upload as well, ping me when the package has reached testing. > Regarding buster I assume I should provide a 2.5+dfsg1-3 on a > debian/buster branch in the repository. I would only add the security > fix, nothing else. Is this the way to go? > That's correct, you should branch from the last buster upload. Please note that you must follow a different process for stable uploads, assuming this will be a buster-updates upload (and not buster-security, which is fine by me), these are the instructions: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions Basically, you create a bug against release.debian.org and wait for the ACK for the upload (freel free to CC me). I suggest taking a look at the current open bugs to look for examples. Thanks for your work :) -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
> > I prepared a new version of libvhdi, release 20201018. > > I have reviewed your changes and they all look fine except for the > symbols file update; > In that commit we can see that there are interfaces being removed, and > any time you get interface removal or signature change you need to > bump the SONAME, as we don't know if any package that depends on it > will break. 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? > 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, -- Samuel Henrique
Re: Request to review and upload libvhdi_20201018-1
Hello Francisco, > I prepared a new version of libvhdi, release 20201018. I have reviewed your changes and they all look fine except for the symbols file update; In that commit we can see that there are interfaces being removed, and any time you get interface removal or signature change you need to bump the SONAME, as we don't know if any package that depends on it will break. As I know you already have previous experience with sleuthkit, this SONAME bump will require a transition as well. For reference: https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I recommend reading the whole section and please feel free to reach out to me or to the list if you have any questions, Thanks for your work -- Samuel Henrique
Re: Request to review and upload dfdatetime_20200824-1
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 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? Thanks, -- Samuel Henrique
Re: Request to review and upload libfsntfs_20200921-1
Hello Team, I usually sponsor Francisco uploads and I advocated for his DM application. Francisco is doing a great job, and I think it would be good if his work got more visibility from the team. I'm thinking about the road to DD, where he will need at least 2 advocates, so he will be sending more requests to review to this list and I'll try to leave them up for someone else. Now if anybody tells me they're fine with advocating someone solely based on the activity on this list, without sponsoring their uploads, I can continue doing the reviews and we move the discussions to here. Thanks, -- Samuel Henrique
Re: Request to review and upload dfdatetime_20200824-1
Hello Team, I usually sponsor Francisco uploads and I advocated for his DM application. Francisco is doing a great job, and I think it would be good if his work got more visibility from the team. I'm thinking about the road to DD, where he will need at least 2 advocates, so he will be sending more requests to review to this list and I'll try to leave them up for someone else. Now if anybody tells me they're fine with advocating someone solely based on the activity on this list, without sponsoring their uploads, I can continue doing the reviews and we move the discussions to here. Thanks, -- Samuel Henrique
Re: DD Ping: ed2k-hash ready for review
Hello Sven, > I updated ed2k-hash [1]. Please review and upload. Done, please feel free to add yourself as an uploader so I can give you DM permissions next time, if that's ok with you. Thanks for your work :) -- Samuel Henrique
Re: Bug#968246: dnstwist: Autopkgtest failure due to depgrecation warning with dnspython 2.0.0
Hello, > On Tuesday, August 11, 2020 1:38:52 PM EDT Peter Wienemann wrote: > > @Security tools team: I requested a review/upload of a new version of > > dnstwist last week [0]. Given Scott's planned NMU it might be good to > > hold off the upload of the new version until the NMU is acknowledged. I'm sorry for that, your request skipped my TODO list, please feel free to ping me directly on the future: dcut ftp-master dm --uid "foss...@posteo.de>" --allow dnstwist Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Picking DM Peter Wienemann with fingerprint 7F44F1E078290D700045BC275D5F6C020398A60A Uploading samueloph-1597179981.dak-commands to ftp-master You should be good to perform the uploads for dnstwist now :) Regards, -- Samuel Henrique
Re: DD Ping - New ncrack package
Hello Marcos, > I tested the package with this patch and it performs well as far as i > can tell. What I was initially worried about were tests that touched that specific part of code, so I was interested in getting a testcase that covered that. I'm not sure if that's the test that you performed but (as per the rest of this email) that's ok. > I also tested it with your suggestion (appending -fcommon CFLAG) and it > also builds and seems to work properly. > > Meanwhile upstream does not adopt a solution, i would prefer to stick > with this hack as the use of -fcommon flag seems to be discouraged at > least by Gentoo distro devs [1] The reason Gentoo discourages that is because it's not fixing the problem upstream, it makes GCC10 fallback to the same behavior as GCC9 (-fcommon), this change is the less intrusive one as we are 100% sure that we will not change the behavior of upstream. I believe the reason Gentoo discourages that is that they want to encourage people to fix upstream. I would say that this is also Debian's position on the matter since we always fix upstream when possible. Although this comes with the presumption that we are sure of the fixes applied and that's where I was a little bit worried, but I took a look at it again and double checked that the variable being removed is unused. debian/0.7+debian-2 sponsored! Thanks for your work Marcos! -- Samuel Henrique
Re: DD Ping - New ncrack package
Hello Marcos, Hmm, I'm kinda wary of the patch you picked[0], it has not been reviewed by upstream yet and it's removing the variable definition instead of making use of a declaration with "external" on the other instance, that's also not what Arch is doing[1] (submitter mentions that they found the issue on Arch). Are you confident that this fix won't introduce any issues and have you considered instead to fix it by making use of the "-fcommon" CFLAG[2]? [0] https://github.com/nmap/ncrack/pull/83 [1] https://github.com/archlinux/svntogit-community/tree/packages/ncrack/trunk [2] https://gcc.gnu.org/gcc-10/porting_to.html#common Thanks, -- Samuel Henrique
Re: help with sleuthkit symbols
Hello, > > I discussed this with Francisco and we decided to drop the symbols > > file for sleuthkit, that is mainly because sleuthkit is in parts > > written by Cpp, but also because the extra complexity on maintaining > > such file is not worth it, considering the only package using > > seluthkit's library is sleuthkit itself. > > Reverse Depends: > libtsk-dev,libtsk13 4.6.5-1 > sleuthkit,libtsk13 4.4.1 > guestfsd,libtsk13 4.2.0 > libguestfs0,libtsk13 4.2.0 Hmm, apparently I missed libguestfs, but that's fine. > Removing the symbols is a bad approach. Symbols are essential to watch > ABI status. Is need to think about the current and future of the > packages depending on the library. Removing the symbols file is the recommended approach for cpp projects, and I think there might be a misunderstanding with regards to what they serve for, they are not essential to watch for ABI status, we use SONAME for that, and each new release needs to be checked regardless of the symbols file (this new release is one bumping the ABI). I understand they do help by optimizing shlibs to not so strictly depend upon new releases, which I don't think takes effect when an ABI bump happens (I'd be curious if that happens). But in general they are a good-to-have thing, not essential, recommended not to have it with cpp projects, and only to be made available by the maintainer if the person really knows what they're doing (as all the symbols need to be carefully checked). >If the problem is only > "symbols-file-contains-current-version-with-debian-revision", simply > remove the revision digit from each line inside the symbols file. As I mentioned before, this wouldn't be enough, a symbols file needs to have each symbol checked, and in the case of sleuthkit, some symbols are coming from the compiler and not sleuthkit itself (sleuthkit currently has an RC bug because of this). I'm also considering the maintenance cost of such thing, which would be not ideal, so I consider it better to just drop the symbols control file. For reference, you can take a look at a recent discussion about a similar case: https://lists.debian.org/debian-devel/2020/07/msg00240.html Regards, -- Samuel Henrique
Re: help with sleuthkit symbols
Hello Team, I discussed this with Francisco and we decided to drop the symbols file for sleuthkit, that is mainly because sleuthkit is in parts written by Cpp, but also because the extra complexity on maintaining such file is not worth it, considering the only package using seluthkit's library is sleuthkit itself. Regards, -- Samuel Henrique
Re: Request to review and upload rhash_1.4.0-1
Hello Aleksey, Given that I knew I wouldn't need to ask for any changes in your upload, I let this review request skip ahead of my TODO list. Uploaded. Just a reminder (I believe I said it before), please apply for DM, I would be happy to advocate for you :) Thanks, -- Samuel Henrique
Re: Intro and Intent to Package
get confused (thinking that a CLA is needed), the copyright information of d/rules would still live in d/copyright. This is not a blocker. d/p/buildflags-override: The patch is fine, but there might be a potential to make it more straightforward, it looks like its goal is to not make use of debhelper flags and strictly follow what's defined in upstream. I understand you probably know most or all of this, but I will try to be detailed; Debhelper does not override flags per se, it just sets them on the environment (setting them through the command line would cause the override), which means the easiest way to not use them is to set the variables in the Makefile with "=" instead of "+=" on the first call to the variable assignment statement. eg.: when the makefile has "CFLAGS +=", one can patch the first assignment statement of that variable to "CFLAGS =", instead of changing all the assignments. The quickest example I could find is from Kali, that's an example of the inverse-case (to use the debhelper flags instead of overriding them) (please note that the patch description and title is wrong though): https://gitlab.com/kalilinux/packages/john/-/blob/kali/master/debian/patches/allow-cflags-overriding.diff Using debhelper flags is advisable since they change as time passes by and they're all chosen with security and reliability in mind (think hardening), this means that the binaries will automatically receive the improvements of the newly defined debhelper flags. For a better visualization of the thing, you can run "blhc --all" on the buildlog to see which flags are missing, this is one of the checks we do on our CI and on the packages in the archive (note: I later found out that this patch wasn't actually overriding the debhelper flags, so blhc will only show findings not related to the patch). I tried to investigate what was the reasoning behind the patch, so let's see if I can help; Seems like the issue is (without the patch): config.cc:85:25: error: ‘bool nsjail::NsJailConfig::has_chroot_dir() const’ is deprecated [-Werror=deprecated-declarations] ... config.cc:86:36: error: ‘const string& nsjail::NsJailConfig::chroot_dir() const’ is deprecated [-Werror=deprecated-declarations] ... config.cc:88:39: error: ‘bool nsjail::NsJailConfig::is_root_rw() const’ is deprecated [-Werror=deprecated-declarations] ... cc1plus: all warnings being treated as errors There are three occurrences of this type of error, debhelper makes it an error, the default is to be a warning. Considering all of this, I can see that the patch does fix the issue, but only because it appends "-Wno-deprecated-declarations" to the CXXFLAGS, please note that doing "override CXXFLAGS +=" would still have the effect of appending to the debhelper flags because of the operator "+=". I have pushed an alternative simplified patch to the branch "debian/samueloph/deprecation_warning", please take a look. There's another alternative to the issue, which is to fix the "deprecated-declarations" warnings in upstream, but working around it with this patch is fine. I also could not really point out what was the deprecation issue based on gcc's output. d/salsa-ci.yml and d/gbp.conf: You can push those files, copying them from another project, but if not, they will eventually get pushed by our script. The benefit is that by pushing the ci definition you will already start making use of it, as the CI is already enabled. https://salsa.debian.org/pkg-security-team/proxytunnel/-/blob/5f0e286858391034ecb9cc72d9f10567d56c9814/debian/salsa-ci.yml https://salsa.debian.org/pkg-security-team/proxytunnel/-/blob/5f0e286858391034ecb9cc72d9f10567d56c9814/debian/gbp.conf d/rules: >From lintian: "I: nsjail: hardening-no-bindnow usr/bin/nsjail": https://lintian.debian.org/tags/hardening-no-bindnow.html You can add the following in d/rules to enable all the hardening flags: "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" It will make debhelper set extra flags to increase the security and reliability of the binaries. Typos: Just in case you've missed it; lintian spotted a few typos on the project, you might wanna fix that or log a ticket. Please note that this is definitely not a blocker and can be addressed in the future, I just wanted to report them out. Alright, I believe that's it, I tried to perform an in-depth review since it's the first contribution to the team and some of the things here are not blockers, please feel free to discuss any of the topics. Thank you for your work and contributions :) Regards, -- Samuel Henrique
Re: Intro and Intent to Package
Hello Christian, > https://mentors.debian.net/package/nsjail Awesome, you don't need to bother with mentors since we are working as a team and we have salsa, anytime you need a review/sponsor you can ask for one and we will take a look at the head of debian/master, that will make things slightly easier. > A few things: > - The package looks lintian clean, except for the distribution. Is > "UNRELEASED" the > correct distribution for now? Or should I change this to "experimental"? The correct distribution will be unstable, that is unless you have an explicit reason to keep it experimental, but those cases are rare and I don't think it applies here. Usually is a good practice to only change when the package is ready to be uploaded, but that's on a best effort basis as a way of minimizing the overhead, this means you are free to err on the side of setting the release to unstable before the package is ready instead of waiting for someone to review to perform the change, sometimes the reviewer/sponsor will do the change themselves when it's ready. So the gist of it is that you can either set it to unstable when you think the package is ready or wait for the sponsor to do so, it's up to you. > - Since I used CDBS, the maximum debhelper compat version I could use is 10. > IIUC, this is fine? I took a look at d/rules and it looks like you're not using anything specific to cdbs, I recommend switching to debhelper fully as cdbs is considered legacy. The switch should be fairly easy, you just need to remove cdbs from B-D and add the vanilla debhelper catch-all target on d/rules: %: dh $@ Note the tab usage (on d/rules), you can take a look at other packages from the team as a reference. I also recommend using "debhelper-compat" in d/control, as the other packages, so you can remove the file d/compat (debhelper-compat declares both the compat level and the debhelper version). With the move to debhelper, you will be able to use version 13. > - Upstream does not provide GPG signatures, so I can ignore the > debian-watch-does-not-check-gpg-signature warning, right? That's right, strictly speaking only lintian errors are blockers, the rest of them are good to fix but sometimes it's not something doable from the packaging side. In this specific case we are talking about a possible improvement that needs to be done on the upstream side (provide a key and signature of tarballs). Considering you're also upstream you can fix it, but it's totally up to you. > Let me know what you think. I'm also a bit unsure about the repo management. > Upstream lives in GitHub and uses Git submodules. For now I uploaded a > snapshot > of the full source tree to debian/master, is that acceptable? What's > the best practice > here? Sorry I didn't review the package yet, so I will comment with a general case in mind; If you package a snapshot of a repo, the version needs to have this information appended in the upstream part of it, like in the example of one package we have: 3.7.18+git20200706.10c91c7-1 instead of 3.7.18-1 Note how the version gives information about the date of the snapshot and the commit picked. This version manipulation is something we do on the packaging side when importing the upstream tarball. Submodules are not an issue, but they might be a little bit cumberstone if the tarballs provided by upstream don't have them checked in (that is, when the submodule usage is not abstracted away in the tarball). Sometimes there are issues related to submodules, but they happen because the submodule is a library that should be packaged separately. Not all libraries need/should be packaged separately, but some do, so it's on a per case basis. I will review the package soon, so I will be able to give a more specific feedback, Thanks for your work, -- Samuel Henrique
Re: Intro and Intent to Package
> I do have some experience with creating packages in Debian format (I > also maintain the commercial BinDiff package [0]), but it'll be good > to take some time and review the Policy :) Cool, in this case you're gonna make good use of lintian, our linter tool that catches some good chunk of policy violations. Llintian gets called on salsa-ci automatically (together with some other tools to check package issues) and it's also a good idea to make sure you run it when building the package locally (if you don't already) so you can catch the issues before pushing. Rrgards, -- Samuel Henrique
Re: Intro and Intent to Package
Hello all, > I have filed 964199 > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964199) for this. > My salsa username is "cblichmann". I created https://salsa.debian.org/pkg-security-team/nsjail and gave you permissions[0]. For the sponsoring of your work, what I would recommend is to either ask for a review in this mailing list or contact someone directly [for when you'd like a specific person to review the work]. Feel free to reach out if you need help with anything, sometimes it might be easier to have someone bootstrap the packaging with all the git branches (upstream, pristine-tar and debian/master), as a summary, what you will need to start the work is: 1) Generate a simple packaging which at least builds, so you get a .dsc artifact, you can generate that with dh_make[1]. 2) Import the generated .dsc into a git structure with "gbp import-orig --pristine-tar build.dsc" 3) Push the repository to salsa, and from now on you can track the work in there, and make use of salsa-ci[2]. Some other small things might change in the repository when I run the script that baselines our projects, which should happen this weekend, but none of these changes will affect your work. Regards, [0] I set and expiration date of end of 2021, as a good practice, when we reach that date, if you're not a DD, somebody can extend that for you with no issues. [1] https://dyn.manpages.debian.org/unstable/dh-make/dh_make.1.en.html [2] I configured the CI in the repo, it will run when a debian/salsa-ci.yml file gets pushed. -- Samuel Henrique
Re: Webhook for arno-iptables-firewall
Hello Sven, > from my observations when having pushed bug fixes for arno-iptables- > firewall I suspect the tagpending webhook [1] is missing from the > project as I never saw pending upload notifications. These > notifications seem to show up regulary for other projects. > > Can you please check this? We periodically run a script that puts our packages in compliance which does, besides other things, set the tagpending webhook, last time I run this was about a month ago, so all the repos created before that should have it. I checked arno and it does have the webhook there, what I believe is happening is that you're not using the format "closes: #" which is what the webhook looks for, basically the commit title has to have the same closes statement that you would put in changelog. > At least for proxytunnel I can see it is set [2], while for arno- > iptables-firewall I cannot even acess the settings [3]. This is happening because you had "Maintainer" permissions on proxytunnel and "Developer" on arno-iptables-firewall, I added the given permission for you with an expiration date of Dec 2022. If by that time you're not a DD, anybody will be happy to extend it. Tell me if you're still having issues, Regards, -- Samuel Henrique
Re: DD Ping: please review proxytunnel
Hello Sven and Julian, Changes force-pushed to the team's repo and package uploaded. Julian, I noticed you will no longer be an Uploader of the package with this new version, I've read your reply to the initial bug report from Sven and I believe that's what you wanted. If not, please let us know. Sven, you did a very good job on the package and I gave you DM permission so you can work on the new upstream release "v1.10.20200507" that happened a few days ago :) Regards, -- Samuel Henrique
Re: DD Ping - New release for nmapsi4
Hello Marcos, dcut ftp-master dm --uid "marcos.fou...@gmail.com" --allow nmapsi4 Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Picking DM Marcos Fouces with fingerprint 7CB8AFFD56032FE35A347D2E6ACCBD0FA3B7447C Uploading samueloph-1589667616.dak-commands to ftp-master Guess you can do this one yourself now, happy uploading :) Regards, -- Samuel Henrique
Re: DD Ping: please review proxytunnel
Hello Sven, I did a review on the package and I have a few comments, I'll split them into letters to help the discussion: A) import of package to git I believe the git repo was created by importing the latest dsc instead of doing: gbp import-dscs --debsnap --pristine-tar --debian-branch=debian/master proxytunnel Which uses debsnap to import all previous dscs. The side effect of this is that you lose the tags pointing to the previous releases and all of them gets bundled up in a single commit. Fixing this requires recreating the git repo with that command, re-applying your changes (you can chery-pick them after adding the current work's remote and doing a git fetch), and force pushing the branches. Now, I won' t ask you to do this, because the practical benefits are not so big considering the latest release is from oldstable and the extra work needed to do it. I'll leave it up to you to decide whether or not to do so, and if you decide to do it, just push it to a new repo under your account and ping me to force push it to our team's repo. B) missing tags Tags seems to be missing in the repo, can you do a git push --tags? There should be tags for the upstream releases and for the debian ones (in this case, only the latest one). C) copyright You can use the command "debmake -k" to check that some copyrights declared are slightly wrong, note that debmake suggests the wrong license and gets confused with the LICENSE.txt file but the findings itself are correct. Some files declared as "GPL-2 with OpenSSL exception" are actually "GPL-2+ with OpenSSL exception" and some MIT are actually ISC. Small things but they need to be addressed. A suggestion I'd like to give is to keep the licenses' long description at the end of the file, to ease the human reading, you declare only what's the license name and then at the end of the file you declare all the licenses' text. Like in this example: https://salsa.debian.org/pkg-security-team/passwdqc/-/blob/be0495e28a511411732810614b7893f1c078f0fb/debian/copyright D) debhelper Since you will have to push changes, you can take this opportunity to also bump DH13. I believe that's all, you did a very good job with the package and I'll be happy to upload it after you solve these small issues. Thanks for your work. Regards, -- Samuel Henrique
Re: DD Ping: please review proxytunnel
Hey, Sorry is taking me so long to review, but I will get to it before the end of the week, As usual, if someone has the time, feel free to do it before me. Regards, -- Samuel Henrique
Re: RFS: New dnstwist upstream version and bug fix (was: Test suite issue fixed for dnstwist)
Hello SZ Lin and Peter, On Sun, 3 May 2020 at 16:09, SZ Lin (林上智) wrote: > Thanks for taking this, I'm on the national holidays. Enjoy your holidays :) > According to the team wiki [1], it elaborates to submit merge requests to > submit the result of the work in most cases. > > Therefore, generally, I review the MR which includes three branches in > Salsa once the repository exists in the team. (talking about this scenario in general, as in this specific case Peter should have permissions to push to the repo and wouldn't need to deal with MR/forking) hmm, we may have to rethink this approach and document that is okay to ask for a review on the person's own fork. Unless Salsa does support multiple branches as source and dest in an MR, but... > IIRC, the MR function in Salsa will handle three different branches > and act accordingly. > (please correct me if I'm wrong) I had tried this in the past and it wasn't a feature, searching online also didn't gave me any results of people managing to do this. Thus I believe it's not possible to do so, if you happen to confirm that it works, please correct me. Peter, the package is good and I uploaded it with a small change in the changelog to put the "new release" statement at the first line. Since this is the first time I sponsor an upload of yours, I will not give you DM permission now, unfortunately, but will happily do so in the next 1/2 uploads. I wasn't aware of the existence of this package, it's very interesting and I will try it out myself for some domains I own, the autopkgtest also leads to some interesting results, hahaha. Thanks for your work -- Samuel Henrique
Re: RFS: New dnstwist upstream version and bug fix (was: Test suite issue fixed for dnstwist)
> 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. -- Samuel Henrique
Re: RFS: New dnstwist upstream version and bug fix (was: Test suite issue fixed for dnstwist)
Hello Peter and SZ Lin, > > Can you send the MR to the team repository[1]? > > > > [1] https://salsa.debian.org/pkg-security-team/dnstwist > > what precisely do you want me to do? Usually a MR relates one source > branch to one destination branch. But the mentioned changes affect three > branches and a tag. How am I supposed to map this to a normal MR? 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 also pushed all your changes to the team's repo, so from now on please feel free to commit there directly. I hope this reduces the overhead of contributing for you. SZ Lin, one thing I usually do when reviewing things like this is, I review the changes on the person's fork and then push them to the official repo when done. an MR might help, but as Peter mentioned, is only doable when only one branch has changes. We are already 7 days after Peter's initial request for review, so if nobody beats me to it, I will do it tomorrow. Regards, -- Samuel Henrique
Re: Granting janitor bot direct commit rights ?
Hi all, > Thus I'm really tempted to grant commit rights. > > What do you think? I think it's a good idea as well. -- Samuel Henrique
Re: DD ping [Brutespray]
Hello Stéphane, > I followed your recommendations and modified the control file. It's cleaner > that way. > (Sorry for the last two commits, it's ugly, I should have been careful and > pushed this in one go) Don't worry, I believe the work we do on Debian is the best way to learn real world git and you will always find something you can improve while at it. > In fact, since several people have been involved in maintaining this package > (including those helping me), > I wonder if my name is really legitimate in the "Uploaders" field of the > d/control file. Well, nobody's gonna say it's not legitimate, that's for sure, the thing is that we always need to have at least one person in the Uploaders field, this person being the first level contact for package issues, the team being the second. For me having my name in the Uploaders field is more about easily spotting things that needs to be made (bugs, new releases...) as I'm unfortunately currently spending most time in those packages other than the ones from the team. Our team does not have strong ownership enforcement so you are definitely encouraged to fix things from other packages and you should put your name as an Uploader if you're interested in it (it's a good idea to contact the current Uploaders through this list first). I noticed the tags "debian/1.6.8-1" and "debian/1.6.7-1" were pushed to the git repo, I removed both and pointed "debian/1.6.8-1" at the right commit, don't forget to remove these tags from your local clone and update from the remote. As a rule of thumb, the person who does the upload of the package is the one who should push the "debian/" tags, preferably signed by their gpg key (which I should/will start doing soon). > Thank you for your patience and your precious help Samuel. You're welcome, I'm happy to help. Package uploaded, keep up the good work :) -- Samuel Henrique
Re: DD ping [Brutespray]
Hello Stéphane, > Upstream was kind enough to push another release 1.6.8 so I wasn't sure if I > had to keep version 1.6.7 in the changelog file. > I finally decided to update the above fields for version 1.6.8, but I'm not > sure so tell me if I was wrong. You did the right thing, we only need to keep the changelog entry if an upload was made. Some people like to keep the release field of the changelog as "UNRELEASED" until right before the upload to denote that, while I rather check the tag to see if there was an upload as changing to UNRELEASED->unstable would require an extra commit just for that. > Thank you for all these clarifications. I think this new v1.6.8 fix now that > ambiguity properly. That's correct, and it was fixed in the best possible way. > I can see another lintian warning "changelog-should-not-mention-nmu", should > I remove the Uploaders line in d/control ? I see that you solved that by changing your name in d/changelog but I do believe you want to change the entry in d/control instead. Just consider that you can chose how your name/email is written and d/control, you also control how it gets automatically written to d/changelog[0] and you need to make those two matches because otherwise our tooling will not recognize the upload as being made from either the maintainer or the uploader (in our case it would need to be marked as team upload). Now, with this in mind, consider which is the way you want to have that written and put your tooling[0] and d/control in sync and you will never again have this issue. The developers reference has some good explanations about NMU and Team Uploads in case you're not aware of it yet[1]. > I also added a quick test (brutespray -h) That's a nice addition, I'd like to ask you to add the restriction "superficial" to it, every test which uses only "-h" should have this restriction, and if you find one without it, feel free to change it. The "skippable" restriction can be removed in favor of "superficial". For more info, you can refer to the docs at [2]. The rest of the package is all fine, so as soon as you update the test (and change your name in d/control, if you decide to follow that way) I will do the upload. Thanks for your work :) [0] You can add this to your bashrc and gbp/dch will pick it up: DEBEMAIL="your email address" DEBFULLNAME="your name" export DEBEMAIL DEBFULLNAME [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-maintainer-uploads-nmus [2] https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst -- Samuel Henrique
Re: DD ping [Brutespray]
Hello Stéphane, Your changes are fine, but there are two issues now: 1) I believe you forgot to update d/changelog with the new changes, you need to add: * Bump to standards-version version 4.5.0 * Add Rules-Requires-Root: no * Update Uploaders field to match changelog 2) If I understood correctly, upstream just re-released 1.6.7, which should never ever happen as it causes confusion as there is now two 1.6.7 releases of brutespray (even if upstream hides the first one). The package is currently not building with gbp as the files are differing, you can see that the pristine-tar branch is not updated and the tag brutespray-1.6.7 points to the first 1.6.7 release. Since this happened, I suggest packaging a git snapshot of the repository, so you can use something like 1.6.7+git20200423.fd9a370-1 and/or suggest upstream to release 1.6.8 since there is ambiguity over 1.6.7, but it could be that only Debian got affected by it. Another alternative would be to fix the pristine-tar and upstream branches to be in sync with the 1.6.7 you want to use, but that might be tricky and in the end I wouldn't be able to see from the version number which of the 1.6.7 releases are you using. That being said, I do understand that the diff between both 1.6.7 versions is very small, and doesn't affect the functionality of brutespray, but now that you imported both to the repo, the issue needs to be solved. Again, my suggestion is to go for the easiest approach to package a git snapshot, as it will make it clear which commit you're using. What are your thoughts on this? Also, as a fun fact, the first ever official release of Debian was 1.1 because the project got bitten by the same issue, although caused by a third party: https://lists.debian.org/debian-announce/1995/msg00010.html Regards, -- Samuel Henrique
Re: Maintaing proxytunnel through the team
Hello all, Sorry I don't have much time to add some meaningful into the conversation, I also think it's better to remove the ".1." as the date + commit id already fulfills its role. Sven, I gave you Developer access to the repo, feel free to push when you'd like to, the package does not need to be ready/working, I just called it out in case you haven't noticed or you'd like to rewrite the history. Feel free to pick the version format you think it's best, we don't enforce a format in the team and I can see there is a good discussion about it in this thread so I'm fine with whatever you pick. Also, thanks for your inputs Marcos and Julian, Regards, -- Samuel Henrique
Re: DD ping [Brutespray]
Hello Stéphane, > > 2) "P: brutespray source: rules-requires-root-missing" Lintian is > > complaining about this[0], I know it's pedantic but it's nice to have, > > tell me if you have questions on how to address it. > > Thanks, If you could show me how to use diffoscope properly, to make > sure everything's okay, I wouldn't say no... :) Alright, so it's fairly simple, diffoscope is available under the diffoscope package, and what you need to do is build the package twice: one time with the package as it is, and one time with the "rules require root" change, then you run diffoscope against the two different .debs that you produced, if the output is empty, then you know that the change didn't affect the binaries and thus it's fine. If there are any differences, then you know you can't apply the change and you don't need to investigate why, but this case is very rare from what I've seen. Regards, -- Samuel Henrique
Re: DD ping [Brutespray]
Hello Stéphane, > I've made a new release of brutespray (debian/1.6.7-1 ). > Could you please review it ? I removed some cruft from the changelog and then noticed an issue, so can you take a look at the following? 1) Your name in d/control is not matching what is in d/changelog, you should fix that and Lintian should not complain about: "brutespray source: changelog-should-mention-nmu" 2) "P: brutespray source: rules-requires-root-missing" Lintian is complaining about this[0], I know it's pedantic but it's nice to have, tell me if you have questions on how to address it. 3) "I: brutespray source: out-of-date-standards-version 4.4.1 (released 2019-09-29) (current is 4.5.0)" Please take a look at the Debian policy upgrade checklist and bump the version to 4.5.0. Thanks for your work on the package! [0] https://lintian.debian.org/tags/rules-requires-root-missing.html -- Samuel Henrique
Re: Maintaing proxytunnel through the team
Hello Sven, I believe the package is a fit for our team yes. The repository is created at https://salsa.debian.org/pkg-security-team/proxytunnel But before the push I'd like to ask you about the latest upstream release imported: 1.9.1+git20200123.1.eff4d41 What's up with the "1.eff4d41" part? I didn't investigate but I assume the last one is part of the git commit hash, but I don't know about the ".1.". I feel like I'm missing something, generally I prefer to use only a date for tarballs coming from git snapshots, and I believe they are more clean, though I recognize it's not as precise as having the commit id. The package is also not building for me, and I believe it's a general issue, it's better if you take a look at that before we push it to the team's repo as you can freely mess with the git history for now. Thanks for your work, -- Samuel Henrique
Re: I'm a DM now, was: Re: arno-iptables-firewall 2.0.3-3 ready for review and upload
Hello Sven, $ dcut ftp-master dm --uid "debma...@g-e-u-e-r.de" --allow arno-iptables-firewall dcut ftp-master dm --uid "debma...@g-e-u-e-r.de" --allow arno-iptables-firewall Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/) Picking DM Sven Geuer with fingerprint 3DF5E8AA43FC9FDFD086F195ADF50EDAF8ADD585 Uploading samueloph-1585779012.dak-commands to ftp-master Done :) Feel free to ping the list, or me, if you have any trouble. Regards, -- Samuel Henrique
Re: Our policy around gbp.conf
Hello all, On Sun, 9 Feb 2020 at 00:25, Samuel Henrique wrote: > > I ended up not doing it before the end of FOSDEM, but will do it soon (in > 7 days time), > > Thanks. It would be nice to have a script to configure our repositories >> with that kind of change. >> >> In Kali I have this: >> https://gitlab.com/kalilinux/tools/packaging/blob/master/bin/auto-update >> https://gitlab.com/kalilinux/tools/packaging/tree/master/auto-update.d >> >> Feel free to re-use adapt and make it available in the pkg-security-team >> repo: >> > > That' s great, will do it. > Just pushed it to all of our packages, I used those scripts and pushed slightly modified versions to the samueloph branch of our pkg-security-team salsa package. Regards, -- Samuel Henrique
Re: Our policy around gbp.conf
I ended up not doing it before the end of FOSDEM, but will do it soon (in 7 days time), Thanks. It would be nice to have a script to configure our repositories > with that kind of change. > > In Kali I have this: > https://gitlab.com/kalilinux/tools/packaging/blob/master/bin/auto-update > https://gitlab.com/kalilinux/tools/packaging/tree/master/auto-update.d > > Feel free to re-use adapt and make it available in the pkg-security-team > repo: > That' s great, will do it. Regards, -- Samuel Henrique
Re: Our policy around gbp.conf
Just a heads up that I will be pushing this before the end of FOSDEM. This is the final version: [DEFAULT] debian-branch = debian/master pristine-tar = True [buildpackage] sign-tags = True [import-orig] filter-pristine-tar = True [pq] patch-numbers = False [dch] multimaint-merge = True Regards, -- Samuel Henrique
About your NMUs on pkg-security packages
Hello Adrian, It's very likely that the pipeline never worked for them and that you were the first one to trigger it. I can't confirm right now but I would say don't worry about it. Regards
Re: arno-iptables-firewall 2.1.0-1 ready for review
Hello Sven, Uploaded, and once again, thanks for your great work. Regards, -- Samuel Henrique
Re: arno-iptables-firewall 2.1.0-1 ready for review
Hello Sven, I believe you forgot to push the pristine-tar branch, can you do it? Regards, -- Samuel Henrique
Re: Our policy around gbp.conf
Hello, > I'm curious about the benefit of putting gbp.conf in each package > > instead of using ~/.gbp.conf. It's painful to have to update this file > > once the team decided to change the default configuration afterward, and > > I didn't see any extraordinary setting that we need. > > Large scale update are not so complicated with the appropriate tools. > Change of gbp.conf doesn't require an upload so it's ok. > > We want external contributors to have the proper settings and we want > contributors who can be part of multiple teams with different settings... > > The most important setting is the "debian-branch" and the "pristine-tar" > one. The others are minor. > Yeah, my idea is that having this as a team policy will reduce the work of the maintainer, as we can automate the creation and update of this file. As Raphaël said, the fundamental ones are debian-branch and pristine-tar, because with them anybody who gbp clones the packages would be able to work on it, even if this person didn't setup their gbp.conf. The minor ones are good to have, as there are no downsides and they seem to fit the workflows people follow in the team. It's important to note that we will be skipping the ci when pushing such things[0] and that he maintenance of the file would not be left to maintainers, we can do it the same way it was with salsa-ci, and I volunteer myself to do it. > > Apart from that, I'm not sure the status of dep14 [1] (it shows > > "draft"), I think it's beneficial for development across the packaging > teams. > > > > [1] https://dep-team.pages.debian.net/deps/dep14/ > > I should probably drop the draft status by now. > +1, I think the "Source", "Recent Changes" and "History" fields also needs to be updated. > > > I agree it's painful to have to update this file when you work in other > > > branches, hence why I use "ignore-branch" and tend to not hardcode the > > > branch in the configuration file.. > > > > How about using .git/gbp.conf (per repository)? > > It doesn't help with the fact that you have to use different values for > "debian-branch" when you are in debian/master or in debian/buster or in > debian/experimental... > +1, and it also hides the file from the salsa wgui, which is not that much of a big deal, but in an similar pro/cons scenario I would rather have it in debian/gbp.conf. [0] https://salsa.debian.org/salsa-ci-team/pipeline#skipping-the-whole-pipeline-on-push -- Samuel Henrique
Re: Our policy around gbp.conf
Hello, > > D) [import-orig] filter-pristine-tar = True > > I don't understand exactly what this does, found this description: "filter > > out files from tarball passed to pristine tar". > > What is this filtering? Can somebody give me an example? > > It just means that we store in pristine-tar the tarball after it has been > filtered (and not before). Ack, this seems like it should be gbp's default. > > D) [pq] patch-numbers = False > > I don't use pq yet, and I feel bad for that, but I don't know what this > > option does > > By default the patches generated in debian/patches/ are named like the > output of "git format-patch", i.e. 0001-Foo.patch, 0002-Bar.patch, etc. > > With this option the numbered prefix is dropped and avoids churns when you > reorder the patch series. Ack, this seems good to me. > > E) [dch] multimaint-merge = True > > I don't understand this option. > > When you generate the changelog, all entries for each maintainer are > grouped in a single block instead of having multiple blocks respecting > the timeline. Got it, also good to me. > > What are your thoughts? > > I would drop "cleaner", "export-dir" and keep the rest. export-dir is > still a matter of personal preference and might require other changes > (like DEBRELEASE_DEBS_DIR=../build-area) to fully benefit from it. Dropped (see updated proposal at the end of email) > > On a side note, I think the option "debian-branch" could support having a > > variable for the current branch as its value, this way gbp.conf could be > > easily reusable in a debian/experimental or debian/whatever branch. > > What do you mean? I mean that debian-branch should support a value like "$this-branch" when set through debian/gbp.conf, and then when gbp parses the config it sets that to the branch which the file persists. This would allow one to use the same file between the different debian/* branches and the current checked out branch would be the debian one. > I agree it's painful to have to update this file when you work in other > branches, hence why I use "ignore-branch" and tend to not hardcode the > branch in the configuration file.. So the disadvantage of debian-branch is that when we branch from debian/master, we need to either change gbp.conf or explicitly pass --debian-branch=debian/NAME to the commands. Considering you said yes to C), I assume your idea is that somebody who doesn't wanna have this problem will set ignore-branch in their ~/.gbp.conf, correct me if I'm wrong. So the updated proposal would be (drop export-dir and cleaner): [DEFAULT] debian-branch = debian/master pristine-tar = True [buildpackage] sign-tags = True [import-orig] filter-pristine-tar = True [pq] patch-numbers = False [dch] multimaint-merge = True Regards, -- Samuel Henrique
Our policy around gbp.conf
Hope you're having nice holidays these days. I was reading our team's wiki[0] again, with attention to one thing that I always felt I didn't understand completely, and so I would like to discuss it with you. In the section "Git packaging tool and repository layout", regarding the suggestion to use ~/.gbp.conf, I wish to propose us to have a default debian/gbp.conf in debian/master of all of our packages. A) pristine-tar = True I think this is already the default, at least that's what I understood from reading gbp.conf(5) and the file /etc/git-buildpackage/gbp.conf. -- I finish reading the manpage and found out that the commented values are not the default ones[2], so by running gbp config buildpackage I found out that pristine-tar is False by default. So I guess this options should stay there. B) cleaner = /bin/true For not running dh_clean before the build, I believe this option is just a complexity saver because we run the build on "../build-area/", this means this option is not critical, but we want it. C) [buildpackage] ignore-branch = True I believe this option could be superseded by "[DEFAULT] debian-branch = debian/master" instead, so we can remove the two current ones we have (other one under [dch]) D) [import-orig] filter-pristine-tar = True I don't understand exactly what this does, found this description: "filter out files from tarball passed to pristine tar". What is this filtering? Can somebody give me an example? E) [import-orig] debian-branch = debian/master Move this one to [DEFAULT], as suggestd in C) D) [pq] patch-numbers = False I don't use pq yet, and I feel bad for that, but I don't know what this option does E) [dch] multimaint-merge = True I don't understand this option. I believe we should agree on which options we want to have as the team' s default and have it on all of our packages (I can do the mass pushing), I assume we will all at least agree on the settings that are fundamental for the packaging to work, like the debian-branch and pristine-tar one, but we can also go a little further and agree on things like "export-dir", "sign-tags" and "cleaner". The first proposal that comes to mind for me, so we have a base to discuss, is the following: [DEFAULT] debian-branch = debian/master pristine-tar = True cleaner = /bin/true [buildpackage] sign-tags = True export-dir = ../build-area/ [import-orig] filter-pristine-tar = True [pq] patch-numbers = False [dch] multimaint-merge = True What are your thoughts? On a side note, I think the option "debian-branch" could support having a variable for the current branch as its value, this way gbp.conf could be easily reusable in a debian/experimental or debian/whatever branch. [0] https://wiki.debian.org/Teams/pkg-security [1] https://wiki.debian.org/Teams/pkg-security#Git_packaging_tool_and_repository_layout [2] I believe all the defaults should be set in /etc/git-buildpackage/gbp.conf instead of in the code, I'll see what the gbp maintainers think of it. -- Samuel Henrique
Re: arno-iptables-firewall 2.0.3-3 ready for review and upload
Hello Sven, > Your suggestion is an honor to me. I just studied what's on nm.d.o and > intend to apply soon. > It's all result of your hard work :) > PS.: If you've been contributing to the team for some time and > > you feel like you're ready to become a DM/DD, feel free to ping > > whoever worked more with you to discuss about it, sometimes > > we just overlook things and forget to ask people to apply. > I forgot to make it more clear, this PS. part is for the rest of the team. I will advocate for you (Sven) as soon as you apply, just ping me. For DM only one advocate is required, more is better, sometimes other people from the team might do it when they see your application, or you might ask them directly, but you already have the required number of advocates so you can start the process as soon as you want, it's your call now to wait or not :) Regards, -- Samuel Henrique
Re: arno-iptables-firewall 2.0.3-3 ready for review and upload
Also, would you like to apply for Debian Maintainer? https://nm.debian.org/ I'd like to give you upload permission for arno-iptables-firewall. This should reduce the delays in the upload :) I'm trying to take a look at the work people has done to the team, sometimes we might miss people who should be DM/DDs already. PS.: If you've been contributing to the team for some time and you feel like you're ready to become a DM/DD, feel free to ping whoever worked more with you to discuss about it, sometimes we just overlook things and forget to ask people to apply. Regards, -- Samuel Henrique
Re: arno-iptables-firewall 2.0.3-3 ready for review and upload
Hello Sven, Uploaded, sorry for the delay. -- Samuel Henrique
Re: testssl.sh 3.0~rc5+dfsg1 in Debian
Hello Unit, > > I really appreciate your work, but version 3.0 of testssl has a licensing issue > > that needs to be resolved before packaging it for Debian: upstream decided to add > > a clause to their GPL license stating that any public use of it must mention where they've > > got the program from. I'm worried as to how this relates to the DFSG, more specifically: > > https://github.com/drwetter/testssl.sh/blob/3b89dc6b0a41299fbf462789998e4c103f4f0210/testssl.sh#L19-L22 > > Correct me if I'm wrong, but from what I'm reading, the section you point to is > already in Debian[0], and was actually there since the initial upload[1]? There > was a minor wording change in 5257c2f3 but as I understand it one was already > bound to the license anyway. I'm not sure, this specific part seems troublesome for me: "If you enclose this script or parts of it in your software, it has to be accompanied by the same license (see link) and the place where to get the recent version of this program." The fact that this license is being called GPL-2 bothers me as well, it's not plain GPL-2. > > I *think* this is ok (didn't thought enough about it) but I feel like a discussion on debian-legal > > would be better and I don't feel confident uploading this without it. > > > > Did you notice that as well? What are you thoughts on it? > > I'd think since the initial upload passed review, the wording change wouldn't be > any cause for alarm since that's just about having to obey the license. But I > would happily read any other opinions! The problem is that d/copyright is wrong as it doesn't say it ins't plain GPL, so it could have happened that ftp-master didn't notice that when reviewing the first upload. I will raise a thread on debian-legal next time I have some free time to see what people think about this. But it's sure that in a best case scenario at least d/copyright will need to be changed. Thanks for your work! -- Samuel Henrique
Re: Request to review and upload snoopy_2.4.6-6
Hello Aleksey, Thanks for working on this, uploaded. You forgot to add the hashtag to the closes entry in changelog, I did that for you. Regards, -- Samuel Henrique
Re: [request-for-help] o-saft maintenance and openssl
S... What I would like to do here is to ask upstream to bundle/vendor the old version of openssl o-saft need, and build it and install inside the o-saft folder and statically linking to it. I would say to try to bundle as minimal things as possible from the old openssl release but I didn't investigate it to know how much realistic this stripping down is. I imagine it could also be possible to try to make it as hard as possible to link against it, but again I didn't investigate so I don't know how realistic this is. Considering upstream is willing to help, this would be good things to ask for, I just don't wanna ask for a bunch of stuff, having upstream spending time implementing it, so then I get blocked later because I asked for something that is unacceptable bu the ftp-master team. So I would like if some other team members could give me some insights on this, if they think this is feasible, or even if they don't have any idea about it. Regards, -- Samuel Henrique
Re: testssl.sh 3.0~rc5+dfsg1 in Debian
Hello Unit, After looking into testssl.sh again, I noticed on the release page[0] it > states > that 2.9.5 won't be supported once 3.0 lands, and encourages distributors > to > pick up 3.0rc5. I did some packaging work[1] to import the new version, > refresh > patches, and other minor things and it'd be cool if you could pull the > changes. > > This version is specifically interesting as it has support for TLS 1.3. > I really appreciate your work, but version 3.0 of testssl has a licensing issue that needs to be resolved before packaging it for Debian: upstream decided to add a clause to their GPL license stating that any public use of it must mention where they've got the program from. I'm worried as to how this relates to the DFSG, more specifically: https://github.com/drwetter/testssl.sh/blob/3b89dc6b0a41299fbf462789998e4c103f4f0210/testssl.sh#L19-L22 I *think* this is ok (didn't thought enough about it) but I feel like a discussion on debian-legal would be better and I don't feel confident uploading this without it. Did you notice that as well? What are you thoughts on it? On a sidenote, if I remember correctly, testsssl suffers from the same issue as o-saft, another ssl vuln detector, as it needs to have an old version of openssl to check for legacy stuff, otherwise it won't support them. Regards, -- Samuel Henrique
[request-for-help] o-saft maintenance and openssl
ed openssl enables the full power of o-saft > me) I'll further improve contrib/install_openssl.sh (installing Perl > mudule > only if missing, trying to install in /usr/share/o-saft/lib, ...) > we) you tell me where you need assistance ;-) > Does it make sence to provide two packages: o-saft and o-saft-dev ? > Then only o-saft-dev has the dependency libperl-critic-perl. > There is already INSTALL.sh which removes the files not used at runtime, > actually it's the diff of o-saft and o-saft-dev :-) > > You may use it like: > env inst=/usr/share/o-saft INSTALL.sh --install --n > > Let me know if I should improve or adapt INSTALL.sh. > So yeah, we need to think about a way of having o-saft with support for all of the openssl things, and also probably split the package into a gui and a dev one. Thanks! [0]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803259 -- Samuel Henrique
tomb (2.6+dfsg1-2~bpo10+1), please review and upload
Uploaded. Regards,
Objections to enable salsa-ci in our packages?
All done, yml pushed and pipelines enabled for all of our packages. I'm fine with it, but please make sure to skip the CI for the initial > push. Otherwise you will have grumpy salsa admins. They asked the python > team to not do this at all. (But python team has many more packages) > > > https://salsa.debian.org/salsa-ci-team/pipeline/#skipping-the-whole-pipeline-on-push > That's interesting, I didn't realize we could control that with the git push command. In order not to trigger the pipeline I just pushed the .yml file before setting up the project to use it, this way it only trigger on the next commit and the yml is already there. > You should also update the configuration in > https://salsa.debian.org/pkg-security-team/pkg-security-team to configure > the non default CI path to debian/salsa-ci.yml. > Done. On Mon, 30 Sep 2019 at 08:05, SZ Lin (林上智) wrote: > Would you update this in the team's wiki? > Wiki updated as well. The next commits will spin up the pipeline, and if anything goes wrong, you will receive an email about it. Happy pipelines everyone!
Objections to enable salsa-ci in our packages?
Hey team, If nobody objects, I will be enabling and pushing salsa-ci.yml to all of our packages soon. Cheers, -- Samuel Henrique
Re: tomb: Bug #935197 fixed, please review and upload new version
Hello Sven, Uploaded, thanks for your work, and congratulations on being listed as an Author[0]. [0] https://github.com/dyne/Tomb/blame/187a627022f759f4f3b8b4fc1c07ccc2dc68ba03/AUTHORS.md#L31 -- Samuel Henrique
Fwd: reducing volument of KGB notifications on IRC
What do you say we do the same on our channel? -- Forwarded message - From: Antonio Terceiro Date: Sat, 17 Aug 2019 at 17:03 Subject: Re: reducing volument of KGB notifications on IRC To: ... > > > To reduce the volume of KGB notifications on IRC, I intend to run the > > > following: > > > > > > $ salsa --group ruby-team update_repo --all --kgb --irc 'debian-ruby&pipeline_only_status=failed&squash_threshold=1' > > > > > > - squash_threshold=1 will make KGB notify only once each time multiple > > > commits are pushed > > > - pipeline_only_status=failed makes KGB notify only when pipelines fail > > > (i.e. no new is good news). > > > > > > This is an attempt to reduce the wall of notifications on #debian-ruby > > > and leave more space for us humans to chat. > > > > > > Thoughts? > > > > I'd always say that it is a good idea to see who's doing what under the > > Ruby team. > > At least, I'd like to see other's commit; helps me explore the different > > ways. For instance, the other day, Daniel's commit of setting and > > exporting LANG/LC_ALL to C.UTF-8 for tests did help me with something I > > was stuck on. > > I am not sure if I'd want to see KGB "squashing" the commits :/ > > But of course, it is a team decision :D > > > > OTOH, I am fine by the CI thingy. Not an ardent fan of viewing CI logs. > > fair enough. I noticed that the python team has two channels: > #debian-python for humans, and #debian-python-changes for notifications. > maybe we could do something similar? Regards, -- Samuel Henrique
Re: Tomb 2.6+dfsg1-1 not migrated to testing
Hello Sven et all, After you sent this email somebody triggered a binNMU so now it should be all fine. I believe this happened because SZ Lin didn't make a source-only upload, and that is required for the testing migration now. Regards, -- Samuel Henrique
Re: Help with t50 i386 non reproducibility, or, possible "march=native" like problem
Hello GengYu Rao, , > So there should be problem with -march=native -ftree-vectorize. Thank, with your help a little bit of investigation I was able to fully understand the problem. Here are the steps I took to investigate: 1) I knew the "march=native" flag was already disabled by a patch we are applying on top of the upstream source code, but I wasn't sure about the "-ftree-vectorize". 2) Looking at the Makefile code[0] I found out that this flag is only used when in amd64, and the reproducibility problems are happening on i386, so let's check the i386 build logs to make sure. 3) The build log[1] of the first try is using the flags: cc -g -O2 -ffile-prefix-map=/build/1st/t50-5.8.3=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu11 -O2 -DNDEBUG -flto -fno-stack-protector -I src/include -std=gnu11 -Wdate-time -D_FORTIFY_SOURCE=2 And the on the second build[2] we have: cc -g -O2 -ffile-prefix-map=/build/t50-5.8.3/2nd=. -fstack-protector-strong -Wformat -Werror=format-security -std=gnu11 -O2 -DNDEBUG -ftree-vectorize -flto -fno-stack-protector -I src/include -std=gnu11 -Wdate-time -D_FORTIFY_SOURCE=2 4) How come -ftree-vectorize is being used on a i386 build log?! Let's check how the Makefile is detecting the architecture[3]: ARCHITECTURE = $(shell arch) 5) Now we just found out that one of the i386 machines used for reproducible builds is doing cross compilation, and that the Makefile is buggy, I fixed this by removing all of the architecture specific stuff[4], and uploaded as 5.8.3-2. Now, are we all in agreement wrt this being a RC bug worth of asking for an unblock to the release team? On an extra sidenote, the Makefile is overriding one of the hardening flags that we use on Debian and our tools are not detecting that, the build is being made with the conflicting flags "-fstack-protector-strong" and "-fno-stack-protector". Thanks for your help GengYu Rao Regards, [0] https://salsa.debian.org/pkg-security-team/t50/blob/e8e1126fade71004fe83a66f78cdc0d2418c4b32/Makefile#L45 [1] https://tests.reproducible-builds.org/debian/rbuild/unstable/i386/t50_5.8.3-1.rbuild.log.gz [2] https://tests.reproducible-builds.org/debian/logs/unstable/i386/t50_5.8.3-1.build2.log.gz [3] https://salsa.debian.org/pkg-security-team/t50/blob/e8e1126fade71004fe83a66f78cdc0d2418c4b32/Makefile#L41 [4] https://salsa.debian.org/pkg-security-team/t50/commit/9b22426eb48a1564ca1415b3916ed2eebecbcc70 -- Samuel Henrique
Help with t50 i386 non reproducibility, or, possible "march=native" like problem
Hello, We've always had problems with t50's new upstream forcing some CPU specific instructions, like hardcoding "march=native" in the Makefile. Usually the main signal of this type of problem is the non-reproducibility of the package, the diff being some assembly instructions. The problem is that we are seeing this happening now[0], and I believe we should make sure that this is not the case before releasing it on Buster. I tried taking a look but couldn't find anything, so I'd like to ask for the team's help, as I know we have people good at this kind of stuff. The main objective here is identify the source of the non-reproducibility on i386, in order to know if it's related to some cpu specific thing being changed at compilation time, which would consist of RC bug. Thanks, [0] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/t50.html . -- Samuel Henrique
mdk4 (0~git20181205-2) is not suitable for Buster
Control: severity -1 serious Thank you for your work Santiago, I appreciate all of the bug reports I've received from you so far. I'm taking the opportunity of this bugreport to bump the severity and block mdk4 from entering Buster, as the current version in Testing is a git snapshot not officially released. Considering we don't know for sure what is causing this FTBFS and that is very likely that there are other bugs in this version, I find it better not to ship it on Buster. Also, for those who need it, there is already mdk3, the previous generation of it, the main difference is that mdk3 doesn't support 5.8Ghz AFAIK. Regards, -- Samuel Henrique
Re: Upload to experimental for dnsrecon
Hi Marcos, Thanks for your support and advice. In the following days (weeks) i > will try to meet some more DD in order to get signatures for my key. > Perfect, if by that time I haven't written an advocacy for your application, ping me and I will look into that, I reckon Raphaël is gonna write one already but you will need two. I have some stuff from DebConf19 to work on during the following days. Thanks, -- Samuel Henrique
Re: Upload to experimental for dnsrecon
Hello all, $ dcut ftp-master dm --uid "marcos.fou...@gmail.com" --allow dnsrecon > Uploading commands file to ftp.upload.debian.org (incoming: > /pub/UploadQueue/) > Picking DM Marcos Fouces with fingerprint > 7CB8AFFD56032FE35A347D2E6ACCBD0FA3B7447C > Uploading samueloph-1555352551.dak-commands to ftp-master > Thanks for all your work Marcos, I've seen that you started the process for becoming a DD but you're missing one more DD signature on your key[0], if you're planning to attend DebConf19[1] by any chance, which is a good way of getting a bunch of signatures, today is the last day to request for bursaries (during the registration part). If not, you will have to find a way of getting one more DD signature before starting the process. Regards, [0]https://nm.debian.org/process/613/keycheck [1]https://debconf19.debconf.org/ -- Samuel Henrique
Re: Request for DM rights for swatch
Hello Marcos, I prepared a bugfix release for swatch [0] in order to close all its > open bugs (just two...). > There's only one bug being closed on d/changelog. > Please, review and upload or give me DM rights on it so i can upload it > myself. Unfortunately, we're out of time for Buster[0], whatever we upload from now on should be treated as a package for the full freeze and must follow the given requirements[1], that is: > Changes which can be considered > >1. targeted fixes for release critical bugs (i.e., bugs of severity >critical, grave, and serious) in all packages; >2. fixes for severity: important bugs in packages of priority: >optional or extra, only when this can be done via unstable; >3. translation updates and documentation fixes that are included with >fixes for the above criteria; > > [0] The minimum age required for a package to migrate to testing is 10 days, and the full freeze starts at 2019-03-12. [1] https://release.debian.org/buster/freeze_policy.html Regards, -- Samuel Henrique
Re: Request for review/upload chkrootkit
Hello Marcos, Uploaded, Thanks, -- Samuel Henrique
Re: Request review/upload recon-ng
Hello Marcos, Sponsored, Thanks -- Samuel Henrique
Re: Request for review/upload of rifiuti 20040505-3
Hello Aleksey, Uploaded, Thanks, -- Samuel Henrique
