Re: RFS: New dnstwist upstream version and bug fix (was: Test suite issue fixed for dnstwist)
Hi Samuel, Samuel Henrique 於 2020年5月3日 週日 下午9:35寫道： > > 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. Thanks for taking this, I'm on the national 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. IIRC, the MR function in Salsa will handle three different branches and act accordingly. (please correct me if I'm wrong) [1] https://wiki.debian.org/Teams/pkg-security SZ > > 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, Raphael Hertzog 於 2020年4月28日 週二 下午9:39寫道： > > Hello, > > I have been approving more and more merge requests of the janitor bot[1] > and I read recently that it's possible to grant commit rights to the bot > so that I don't have to approve them manually. > > [1] example: > https://salsa.debian.org/pkg-security-team/ccrypt/-/merge_requests/1 > > While I didn't like this idea at the start, it's true that the changes > proposed are rather unintrusive and they are well tested, the bot ensures > that the package still builds and that there are no meaningful differences > between both builds (with and without the patch). > > Thus I'm really tempted to grant commit rights. > > What do you think? I second that. I look forward to seeing the Janitor share the portion of the maintenance work. SZ > > Cheers, > > PS: salsa is currently down due to some hardware issue so the link doesn't > work right now > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS >
Re: RFS: dnstwist
Hi Peter, Peter Wienemann 於 2020年3月27日 週五 上午2:12寫道： > > Hi SZ, > > On 25.03.20 04:39, SZ Lin (林上智) wrote: > > Thanks for your contribution, I've created this repository and import your > > commits in the pkg-security team. > > > > [1] https://salsa.debian.org/pkg-security-team/dnstwist > > [...] > > > I didn't see any issues, but one thing to be aware of that someone > > also wrote a manpage of dnstwist and sent the PR to the upstream. > > > > [2] https://github.com/elceef/dnstwist/pull/91/files > > thank you for your review, the repository creation and the upload. > > Concerning the manpage, I will discard the present one as soon as the > mentioned PR has been merged. Thanks. > > Do I have permission to push updates to the newly created repository? Regarding the commit right, please refer to the below link [1], you can send the MR even though you don't have the commit right in dnstwist. [1] https://wiki.debian.org/Teams/pkg-security#Get_commit_rights SZ > > Peter >
Re: RFS: dnstwist
Hi Peter, Peter Wienemann 於 2020年3月23日 週一 上午3:59寫道： > > Dear DDs, > > I prepared packaging for the domain name permutation engine "dnstwist" > (ITP bug #948237). The git repository is currently available at > > https://salsa.debian.org/wiene-guest/dnstwist Thanks for your contribution, I've created this repository and import your commits in the pkg-security team. [1] https://salsa.debian.org/pkg-security-team/dnstwist > > It would be great if someone could review the code, provide feedback and > - once everything looks fine - transfer the repository to the security > tools team area and upload the package. I didn't see any issues, but one thing to be aware of that someone also wrote a manpage of dnstwist and sent the PR to the upstream. [2] https://github.com/elceef/dnstwist/pull/91/files SZ > > Thanks, Peter >
Re: DD ping
Hi Marcos, Marcos Fouces 於 2020年3月23日 週一 上午12:58寫道： > > Hello Sz Lin > > Oops! I didn't aware of this serious licencing bug. Apart of that, > upstream developer of websploit (0x0ptim0us-guest) is a also a member > of our team and would start commiting soon. He is aware of the patch. Thanks for the information, the package has been uploaded. SZ > > Thanks for your review! > > Greetings, > Marcos. > > > > El dom, 22-03-2020 a las 22:52 +0800, SZ Lin (林上智) escribió: > > Hi Marcos, > > > > Marcos Fouces 於 2020年3月19日 週四 上午1:34寫道： > > > Hello > > > > > > I updated snoopy in order to fix a bug (and other minor > > > housekeeping). > > > > > > Could you please, check and upload. > > > > Thanks for your contribution. > > > > I've reviewed the package and found a serious bug. > > According to the content of the current license, the license > > should be Expat [1] instead of GPL-3+ in the current d/copyright [2]. > > > > I've fixed this issue and pushed it to salsa [3], and I plan to > > upload this > > package these days. > > > > Apart from that, it will be great if you can send the d/patch and > > manpage to the upstream. > > > > [1] > > https://salsa.debian.org/pkg-security-team/websploit/-/blob/debian/master/LICENSE.txt > > [2] > > https://salsa.debian.org/pkg-security-team/websploit/-/blob/debian/master/debian/copyright > > [3] > > https://salsa.debian.org/pkg-security-team/websploit/-/commit/bbd0bfefdb9433b0408b414a1d54006401d996b3 > > > > SZ > > > > > Bonus: please give me upload right so i could avoid bother you with > > > this in the future. > > > > > > Greetings, > > > > > > Marcos > > > >
Re: DD ping
Hi Marcos, Marcos Fouces 於 2020年3月19日 週四 上午1:34寫道： > > Hello > > I updated snoopy in order to fix a bug (and other minor housekeeping). > > Could you please, check and upload. Thanks for your contribution. I've reviewed the package and found a serious bug. According to the content of the current license, the license should be Expat [1] instead of GPL-3+ in the current d/copyright [2]. I've fixed this issue and pushed it to salsa [3], and I plan to upload this package these days. Apart from that, it will be great if you can send the d/patch and manpage to the upstream. [1] https://salsa.debian.org/pkg-security-team/websploit/-/blob/debian/master/LICENSE.txt [2] https://salsa.debian.org/pkg-security-team/websploit/-/blob/debian/master/debian/copyright [3] https://salsa.debian.org/pkg-security-team/websploit/-/commit/bbd0bfefdb9433b0408b414a1d54006401d996b3 SZ > > Bonus: please give me upload right so i could avoid bother you with > this in the future. > > Greetings, > > Marcos >
Re: Our policy around gbp.conf
Hi, Raphael Hertzog 於 2019年12月30日 週一 下午5:28寫道： > > Hi, > > On Mon, 30 Dec 2019, Samuel Henrique wrote: > > 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. > > Yeah, we should do that. 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. 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/ > > > 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. > > Yeah, but we don't need it anymore apparently: >--git-cleaner=CLEAN_CMD > Use CLEAN_CMD to clean the source tree before the build. The > default is /bin/true (no cleaning). > > > 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]) > > Yes. > > > 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). > > > E) [import-orig] debian-branch = debian/master > > Move this one to [DEFAULT], as suggestd in C) > > Yes. > > > 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. > > > 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. > > By default you have: > > [ A ] > * Change 1 > > [ B ] > * Change 2 > > [ A ] > * Change 3 > > With this option you have: > > [ A ] > * Change 1 > * Change 3 > > [ B ] > * Change 2 > > It's really esthetical mainly (and saving a few lines). > > > 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? > > 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. > > > 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 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)? SZ > > Cheers, > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS >
Re: New version of openvas renamed to gvm
Hi Sophie, Sophie Brun 於 2019年12月21日 週六 00:42 寫道： > Hi SZ, > > I think that packaging is done. I asked Raphaël to upload in experimental. > The repo in salsa has been changed form openvas-libraries to gvm-libs. > Thank you for your effort. There are some remaining tasks such as transition package and ITP email for new package. I will start to work on that. > I will work on the other packages next week (but there is Christmas...) > Merry Christmas! SZ > Sophie > > Le 17/12/2019 à 09:05, SZ Lin (林上智) a écrit : > > Hi Sophie, > > > > I've pushed the current work to here [1], and I think the packaging > > task is almost done. > > > > [1] https://salsa.debian.org/szlin/openvas-libraries > > > > SZ > > > > Sophie Brun 於 2019年12月10日 週二 下午8:27寫道： > >> > >> Hi SZ, > >> > >> Yes please upload your current work and I will try to finish the > packaging. > >> > >> Thanks, > >> Sophie > >> > >> Le 10/12/2019 à 11:43, SZ Lin (林上智) a écrit : > >>> Hi Sophie, > >>> > >>> > >>> After two weeks later, I still have little time on upgrading openvas > to gvm. > >>> > >>> I plan to upload current work to a temporary repository, and you can > >>> take over the packaging task if you are interested. > >>> > >>> What do you think? > >>> > >>> SZ > >>> > >>> SZ Lin (林上智) 於 2019年11月21日 週四 下午10:30寫道： > >>> > >>>> > >>>> Hi Sophie, > >>>> > >>>> Sophie Brun 於 2019年11月20日 週三 下午6:42寫道： > >>>>> > >>>>> Hi SZ, > >>>>> > >>>>> I would like to see openvas updated. I can work on the updates. But > maybe you start > >>>>> to work on the new versions? > >>>> > >>>> Yes, I'm working on that, but the task behind the expected schedule > >>>> due to hectic months. > >>>> > >>>> I will be available to restart the packaging task after this week. > >>>> > >>>>> > >>>>> Do you think we should keep the current git repo to keep the history > and change > >>>>> the git repo name with source package name? > >>>> > >>>> Yes, I think it makes sense. As you know, it's not the first time > >>>> changing the name in openvas. > >>>> > >>>> SZ > >>>> > >>>>> Or should we create new git repo? > >>>>> > >>>>> Thanks > >>>>> Regards, > >>>>> Sophie > >>>>> > >>>>> Le 16/05/2019 à 13:30, SZ Lin (林上智) a écrit : > >>>>>> Hi Team, > >>>>>> > >>>>>> Since "openvas" project renamed to "gvm" [1], I proposed below > changes > >>>>>> for adopting new version of "gvm" (a.k.a."openvas") > >>>>>> > >>>>>> * openvas -> gvm (and openvas will become transition package [2]) > >>>>>> * openvas-libraries 9.0.0 -> gvm-libs 10.0.0 > >>>>>> * openvas-scanner 6.0.0 (not changed) > >>>>>> * openvas-manager 7.0.0 -> gvmd 8.0.0 > >>>>>> * greenbone-security-assistant 7.0.0 -> gsa 8.0.0 > >>>>>> * openvas-cli 1.4.5 (abandoned) -> gvm-tools 2.0.0 > >>>>>> > >>>>>> Please feel free to add any input or suggestions. > >>>>>> > >>>>>> Thank you. > >>>>>> > >>>>>> [1] https://github.com/greenbone > >>>>>> [2] https://wiki.debian.org/RenamingPackages > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> SZ > >>>>>> > >>>>>> > >>>>> > >>> >
Re: New version of openvas renamed to gvm
Hi Sophie, I've pushed the current work to here [1], and I think the packaging task is almost done. [1] https://salsa.debian.org/szlin/openvas-libraries SZ Sophie Brun 於 2019年12月10日 週二 下午8:27寫道： > > Hi SZ, > > Yes please upload your current work and I will try to finish the packaging. > > Thanks, > Sophie > > Le 10/12/2019 à 11:43, SZ Lin (林上智) a écrit : > > Hi Sophie, > > > > > > After two weeks later, I still have little time on upgrading openvas to gvm. > > > > I plan to upload current work to a temporary repository, and you can > > take over the packaging task if you are interested. > > > > What do you think? > > > > SZ > > > > SZ Lin (林上智) 於 2019年11月21日 週四 下午10:30寫道： > > > >> > >> Hi Sophie, > >> > >> Sophie Brun 於 2019年11月20日 週三 下午6:42寫道： > >>> > >>> Hi SZ, > >>> > >>> I would like to see openvas updated. I can work on the updates. But maybe > >>> you start > >>> to work on the new versions? > >> > >> Yes, I'm working on that, but the task behind the expected schedule > >> due to hectic months. > >> > >> I will be available to restart the packaging task after this week. > >> > >>> > >>> Do you think we should keep the current git repo to keep the history and > >>> change > >>> the git repo name with source package name? > >> > >> Yes, I think it makes sense. As you know, it's not the first time > >> changing the name in openvas. > >> > >> SZ > >> > >>> Or should we create new git repo? > >>> > >>> Thanks > >>> Regards, > >>> Sophie > >>> > >>> Le 16/05/2019 à 13:30, SZ Lin (林上智) a écrit : > >>>> Hi Team, > >>>> > >>>> Since "openvas" project renamed to "gvm" [1], I proposed below changes > >>>> for adopting new version of "gvm" (a.k.a."openvas") > >>>> > >>>> * openvas -> gvm (and openvas will become transition package [2]) > >>>> * openvas-libraries 9.0.0 -> gvm-libs 10.0.0 > >>>> * openvas-scanner 6.0.0 (not changed) > >>>> * openvas-manager 7.0.0 -> gvmd 8.0.0 > >>>> * greenbone-security-assistant 7.0.0 -> gsa 8.0.0 > >>>> * openvas-cli 1.4.5 (abandoned) -> gvm-tools 2.0.0 > >>>> > >>>> Please feel free to add any input or suggestions. > >>>> > >>>> Thank you. > >>>> > >>>> [1] https://github.com/greenbone > >>>> [2] https://wiki.debian.org/RenamingPackages > >>>> > >>>> -- > >>>> > >>>> SZ > >>>> > >>>> > >>> > >
Re: New version of openvas renamed to gvm
Hi Sophie, After two weeks later, I still have little time on upgrading openvas to gvm. I plan to upload current work to a temporary repository, and you can take over the packaging task if you are interested. What do you think? SZ SZ Lin (林上智) 於 2019年11月21日 週四 下午10:30寫道： > > Hi Sophie, > > Sophie Brun 於 2019年11月20日 週三 下午6:42寫道： > > > > Hi SZ, > > > > I would like to see openvas updated. I can work on the updates. But maybe > > you start > > to work on the new versions? > > Yes, I'm working on that, but the task behind the expected schedule > due to hectic months. > > I will be available to restart the packaging task after this week. > > > > > Do you think we should keep the current git repo to keep the history and > > change > > the git repo name with source package name? > > Yes, I think it makes sense. As you know, it's not the first time > changing the name in openvas. > > SZ > > > Or should we create new git repo? > > > > Thanks > > Regards, > > Sophie > > > > Le 16/05/2019 à 13:30, SZ Lin (林上智) a écrit : > > > Hi Team, > > > > > > Since "openvas" project renamed to "gvm" [1], I proposed below changes > > > for adopting new version of "gvm" (a.k.a."openvas") > > > > > > * openvas -> gvm (and openvas will become transition package [2]) > > > * openvas-libraries 9.0.0 -> gvm-libs 10.0.0 > > > * openvas-scanner 6.0.0 (not changed) > > > * openvas-manager 7.0.0 -> gvmd 8.0.0 > > > * greenbone-security-assistant 7.0.0 -> gsa 8.0.0 > > > * openvas-cli 1.4.5 (abandoned) -> gvm-tools 2.0.0 > > > > > > Please feel free to add any input or suggestions. > > > > > > Thank you. > > > > > > [1] https://github.com/greenbone > > > [2] https://wiki.debian.org/RenamingPackages > > > > > > -- > > > > > > SZ > > > > > > > >
Re: Bug#936448: dtfabric: Python2 removal in sid/bullseye
Hi Hilko, Hilko Bengen 於 2019年11月27日 週三 下午4:47寫道： > > * SZ Lin (林上智): > > > I'm going to remove python2 support in dtfabric, and this action will > > affects below packages which you maintained. > > > > Reverse Depends: > > Depends: python-plaso (>= 20181128) > > Depends: python-dfvfs (>= 20170524) > > Depends: python-dfwinreg (>= 20170524) > > I had also planned to do this for all the other ~20 Plaso dependencies > some time this week. Going to start later today or tomorrow. Thanks for your information. I've uploaded "dtfabric" to the 7-day delayed queue. SZ > > Cheers, > -Hilko
Re: [Fwd: Re: Tomb package 2.5 > 2.6]
Hi Sven, Sven Geuer 於 2019年10月4日 週五 上午3:12寫道： > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi Team, > > I received a request to bring tomb 2.6 to buster (see forwarded mail > below). I believe backports is the way to go. Do you agree? I've skimmed the commits between 2.5 and 2.6, and many commits are not related to security fixes. Therefore, I think buster-backport is more suitable for this case if you want to use tomb 2.6 in Debian 10. Moreover, if there is any specific security issue (e.g., CVE) need to be fixed, the buster-security is the way. SZ > > @Dmitry: I'm not sure why you consider tomb 2.6 a security update. > Anyway, to emphasize your request I suggest you open up a whishlist bug > against tomb. > > Sven > > - Weitergeleitete Nachricht > Von: Dmitry Elmanov > An: Sven Geuer > Betreff: Re: Tomb package 2.5 > 2.6 > Datum: Thu, 3 Oct 2019 14:11:22 +0300 > > > Dear Sven > > > > Tomb 2.6 safely settled in the Testing. Thank you. > > In my opinion, there are all signs that version 2.6 > > is a "security update", and therefore may come to > > a stable branch. Is it possible? Or backports...? > > > > Best regards, > > Dmitry Elmanov > > > > > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl2WRakACgkQrfUO2vit > 1YWS7g/9HoeQkkz14koe0iBfC6pqDFxgkLyFcdB4GOUF6eu3A6kHdSsfYDj4g33F > kUwANU2aZ3ep3plkb6bS5SmpDRt3g1Mwvd+za0rlQNyEu2lnbqOUZKEqpcRg4xl7 > BLkbevYeDCc36WOg2GgxtaQ0+PBeVTl0k19jeQgP0CIHcwKDGt3wkjS89NAsanqn > IICiP3sLN3yFWtpPiK6KkUrQ0P2hCU7xDSdutKxNw0uRLzGL7iemX8vmD+SzjCDe > QtZaY2HW3lrMPcPjWgbmj90y4wsufuEWduKGJSl0XWXDX/vhGQLBFOJMCb2C19lV > kASTBzcldhxLakqeOkW4GomS2GajO1TQ//mY8P2/KIYjlIxEmt8XUxWjm3CU/F+O > khPrC8ZNZ6eW+kf+Xw7suKKnTirSI5MvWKtnJRklh/ufVXlEY5ALAz/enesKQ6jx > bMz4FwMM1amvc5qlsKOlFHMLUuDP2KxmHvcum5aZnbs0M5VLETviRKcRSrOWh9Yh > YkB/scyHS0CYHDgOr1umpEeV7XcQSmlOpx6/yb3m4UrVnSMeCHCZI5tjSb43NFo2 > yb3gjduPCsXJ0/Snpyw7MXeKemtFV4RJXp20StKokAB+bjyDVkhILDLTaay/Iw5t > FvZPz0+s4NY8f547dRpofbjVdPbnulFlNP8Fgu2FN+oZr4b2NXM= > =a+4B > -END PGP SIGNATURE- >
Re: Objections to enable salsa-ci in our packages?
Hi Samuel, Samuel Henrique 於 2019年9月30日 週一 上午6:02寫道： > > Hey team, > > If nobody objects, I will be enabling and pushing salsa-ci.yml to all of our > packages soon. Thanks to Samuel, I think it makes sense to add this configuration to ensure the quality of the packages. It would be better if we can use the same format and process with this yml file. Would you update this in the team's wiki? SZ > > Cheers, > > -- > Samuel Henrique
Re: Tomb 2.6+dfsg1-1 not migrated to testing
Hi Sven, Sven Geuer 於 2019年8月20日 週二 上午1:51寫道： > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello Samuel et all, > > it has been built for amd64 by buildd now. Unfortunately it's still not > migrated. > > Any clue? It's already in testing archive [1]. [1] https://tracker.debian.org/news/1056037/tomb-26dfsg1-1-migrated-to-testing/ > > Sven > > Am Sonntag, den 18.08.2019, 19:33 +0100 schrieb Samuel Henrique: > > 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, > > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl1a4UoACgkQrfUO2vit > 1YUODQ/+KCI12XIMn2Ri5jFyM+t/weA4Z3AAYgAGwp5eWlF6L/QtGQ2kXPwk8GpB > TGN5f4Olu+YEbwosAAkHbshIr2iG1Trak+Cubz04LCHRZwDSyWedestHwP8GuM00 > jeRIfPFs0C3vhO8QVmFt2aZOH5/wRRDK04/WF0KD0sSRMBbcUrEiH0VHsEYNFBaE > zuKQqDzpjPyBB48iTQup/L5fL6WzzSJpjcJVv6VaCkOJUpkghq+ble0q0Pw1uLoJ > cBWaKTfO+R/t8WR5/ZTdCu9IKFIt+g4JumXU2EBatWIO5RK5H7GIorneyP0YDNKE > XepucOR6h2Oas4jHWdfpAAGjB0ZTLCAKMqWVrhlT9WumWplY7UTjQBjTAUdH5zQt > A9QU4ATSrz8msQcoPtYSg06tj9WzB6TCh5KjXnJCol8AmiOT5Gr6bGRUM5Ek89Qn > Jjdm/WVSfE53ICAy+ghLqQudwocGpN7HNnANpct7Oc7xruSfNta5FU5Tsyz49py4 > SdgHb9dc+z+18/RB8ihFc9/lNWwAHQVUk7cvPOAVqeu09IQz3aOGTPgpoXRs7s/F > YDnPYc5Mj5E0diejDCbjK3A4flGpB8JVCVaqAR1DgSPdujdW5X453KpYiwazYtYR > K5G1nnzSOl+IUZSPxO4EbDWapB42qNWmTVNBS0/Tur0ezPeKgQk= > =VGf8 > -END PGP SIGNATURE- >
Re: 2. Reminder: tomb: all open bugs fixed, new upstream version, please review
Hi Sven, Sven Geuer 於 2019年8月8日 週四 上午1:58寫道： > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi SZ, > > ftp-master did not recognize the bugs closed with the previous and > unreleased version 2.5+dfsg1-3. The package is in DELAYED queue [1] and not accept into unstable yet. [1] https://ftp-master.debian.org/deferred.html > > Are special means required, so that bugs.debian.org will see and > process them? The bug can be closed by sending email to nnn-d...@bugs.debian.org [2] [2] https://www.debian.org/Bugs/Developer SZ > > Sven > > Am Mittwoch, den 07.08.2019, 19:30 +0200 schrieb Sven Geuer: > > Hi SZ, > > > > than you for your review and your suggestions. > > > > I did sent the patches to upstream some time ago. They already found > > their way into newer, still unreleased code. > > > > Sven > > > > Am Mittwoch, den 07.08.2019, 19:11 +0800 schrieb SZ Lin (林上智): > > > Hi Sven, > > > > > > Sven Geuer 於 2019年8月4日 週日 下午5:15寫道： > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA512 > > > > > > > > Hello Team, > > > > > > > > my latest work on tomb still needs to be reviewed and uploaded. > > > > Please > > > > see my previous mail on this topic, also forwarded below. > > > > > > > > I would appreciate receiving some feedback. > > > > > > Thank you for your efforts, the package has been uploaded to 7-days > > > delayed queue. > > > > > > I've skimmed your changes and made some changes [1] > > > > > > [1] > > > https://salsa.debian.org/pkg-security-team/tomb/tree/debian/master > > > > > > + * Remove unnecessary files in .pc > > > + * d/control: > > > +- Bump Standards-Version to 4.4.0 > > > + * d/source/lintian-overrides > > > +- Remove unnecessary lintian-override > > > > > > I think it's unnecessary to add that lintian-override, furthermore, > > > the commit > > > 75b44059225136575059477261767468d86aa63f contains multiple changes. > > > Therefore, this modification cannot be reverted. It would be nice > > > if > > > you split into > > > multiple commits next time. > > > > > > + * d/upstream/metadata: > > > +- Tidy content of metadata > > > > > > Aside from that, I suggest you send d/patches back to upstream. > > > > > > SZ > > > > > > > Sven > > > > > > > > - Weitergeleitete Nachricht > > > > Von: Sven Geuer > > > > An: Debian Security Tools Packaging Team < > > > > debian-security-tools@lists.debian.org> > > > > Betreff: tomb: all open bugs fixed, new upstream version, please > > > > review > > > > Datum: Thu, 04 Jul 2019 22:30:23 +0200 > > > > > > > > > Hello Team, > > > > > > > > > > I fixed all currently open bugs and packaged the most recent > > > > > upstream > > > > > version of tomb [1] which came out during my work. Please > > > > > review > > > > > and > > > > > upload. > > > > > > > > > > Because of bug #930782 [2] it should also go into Buster after > > > > > this > > > > > is > > > > > released, I believe. Either with the next point release or via > > > > > buster- > > > > > backports. Which is the way to go? > > > > > > > > > > These are the changes: > > > > > > > > > > tomb (2.6+dfsg1-1) unstable; urgency=medium > > > > > > > > > > * Team upload. > > > > > [Sven Geuer] > > > > > * New upstream release > > > > > - Adapt d/patches/* to new release > > > > > * Add further missing dependencies and correct existing ones > > > > > * Make package lintian clean > > > > > - Add debian/tests/* for autopkgtest > > > > > - Add linitian override for unavailabe upstream gpg > > > > > signature > > > > > - Fix for lintian info debian-watch-contains-dh_make- > > > > > template > > > > > - Add patch for three lintian infos spelling-error-in- > > > > > manpage > > > > > > > > > > tomb (2.5+dfsg1-3) UNRELEASED; urgency=medium > > > > > >
Re: 2. Reminder: tomb: all open bugs fixed, new upstream version, please review
Hi Sven, Sven Geuer 於 2019年8月4日 週日 下午5:15寫道： > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hello Team, > > my latest work on tomb still needs to be reviewed and uploaded. Please > see my previous mail on this topic, also forwarded below. > > I would appreciate receiving some feedback. Thank you for your efforts, the package has been uploaded to 7-days delayed queue. I've skimmed your changes and made some changes [1] [1] https://salsa.debian.org/pkg-security-team/tomb/tree/debian/master + * Remove unnecessary files in .pc + * d/control: +- Bump Standards-Version to 4.4.0 + * d/source/lintian-overrides +- Remove unnecessary lintian-override I think it's unnecessary to add that lintian-override, furthermore, the commit 75b44059225136575059477261767468d86aa63f contains multiple changes. Therefore, this modification cannot be reverted. It would be nice if you split into multiple commits next time. + * d/upstream/metadata: +- Tidy content of metadata Aside from that, I suggest you send d/patches back to upstream. SZ > > Sven > > - Weitergeleitete Nachricht > Von: Sven Geuer > An: Debian Security Tools Packaging Team < > debian-security-tools@lists.debian.org> > Betreff: tomb: all open bugs fixed, new upstream version, please review > Datum: Thu, 04 Jul 2019 22:30:23 +0200 > > > Hello Team, > > > > I fixed all currently open bugs and packaged the most recent upstream > > version of tomb [1] which came out during my work. Please review and > > upload. > > > > Because of bug #930782 [2] it should also go into Buster after this > > is > > released, I believe. Either with the next point release or via > > buster- > > backports. Which is the way to go? > > > > These are the changes: > > > > tomb (2.6+dfsg1-1) unstable; urgency=medium > > > > * Team upload. > > [Sven Geuer] > > * New upstream release > > - Adapt d/patches/* to new release > > * Add further missing dependencies and correct existing ones > > * Make package lintian clean > > - Add debian/tests/* for autopkgtest > > - Add linitian override for unavailabe upstream gpg signature > > - Fix for lintian info debian-watch-contains-dh_make-template > > - Add patch for three lintian infos spelling-error-in-manpage > > > > tomb (2.5+dfsg1-3) UNRELEASED; urgency=medium > > > > * Team upload. > > [ Sven Geuer ] > > * Add several missing Recommends and Suggests (Closes: #924042). > > - gettext-base, lsof, dcfldd, qrencode, unoconv, steghide, swish- > > e > > * d/control: > > - Bump Standards-Version to 4.3.0 > > - Bump DH version to 12 > > * d/compat: > > - Bump compat to 12 > > * d/copyright: > > - Normalize Copyright fields according to DEP-5 > > - Update * copyright > > - Update debian/* copyright > > * Add kdf helper binaries to the package (Closes: #924043) > > - d/control: > > - Change Architecture to 'any' > > - Add required Build-Depends and Depends > > - Add d/patches/include-kdf-binaries.patch > > - d/rules: > > - Add overrides for dh_auto_clean/build/install > > * Fix default cipher > > - Add d/patches/fix-default-cipher.patch (Closes: #930782) > > - d/control: > > - Correct cipher mentioned in the description > > * Fix error messages on opening a new tomb (Closes: #931027) > > - Add d/patches/fix-errors-on-open.patch > > > > Cheers, > > Sven > > > > [1] https://salsa.debian.org/pkg-security-team/tomb > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930782 > > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl1GodsACgkQrfUO2vit > 1YUgcxAAwk0HcqbSUIkwgxJoGdkWmU8LOdqJYaS9BxlP3/DmqoF139mFRFTv1LA+ > YpwYBblGieTU4Q4xtiOhYdhKtzPTVyMq4/NOsL4BMgqEbXJDLWbvxZWvjHuj1R7k > R32zmFBjk69+Ehe58RLen9+JaiEp1TUKZFrfdc22Ck9fYDwt8wxv2jU/azjJ3kwa > X/ZNbEXaSzWFYlrKc8YQHUaFfNntEjqkxalKZ4siGFzd7LAOMx8DFTkuVsTsuAho > Un4tPTUg3CU8h65r6sp6a1dilzw9R3+/eUZbEhDsyPinTqiOaYj1YhLl4vwNFSKW > +XmJeyw5FG5qN6GAz1tocQXrYzxSiQoBiPS/3k1QBDqMQHWuSWaWX1rLGCAMQ7S2 > qZQJTYPtJZKIeVmIfLh6XFFhMNaXpUG410hxT7DapfSFdZ1AfPpUB1jQSXjQFG8z > QD3UtLxfu2jz+cKpRV8PrA8mydDfK8qmTp0wZBGToyR9dQvjGcZzfBe1ttKc9jbn > nXVgDKTjIIx+LBfk2aTgze/E3V54SzdVgJEPH0wVj6zwm/QivIFSwPmfwoAmWp7M > acFgqPrFOOjRxIPVsUfUV2iOqlBQ+7CFyUAzSJmahUJFMke7UOHHcoAh0GWTwTYH > 6qzDkVm1ucGV0pHd/sGZsEYCopZG610caByPhb7IUGoH8l1V3po= > =1yIC > -END PGP SIGNATURE- >
New version of openvas renamed to gvm
Hi Team, Since "openvas" project renamed to "gvm" [1], I proposed below changes for adopting new version of "gvm" (a.k.a."openvas") * openvas -> gvm (and openvas will become transition package [2]) * openvas-libraries 9.0.0 -> gvm-libs 10.0.0 * openvas-scanner 6.0.0 (not changed) * openvas-manager 7.0.0 -> gvmd 8.0.0 * greenbone-security-assistant 7.0.0 -> gsa 8.0.0 * openvas-cli 1.4.5 (abandoned) -> gvm-tools 2.0.0 Please feel free to add any input or suggestions. Thank you. [1] https://github.com/greenbone [2] https://wiki.debian.org/RenamingPackages -- SZ
Re: Request for review/upload of metacam 1.2-11
Hi Aleksey, Aleksey Kravchenko 於 2019年1月20日 週日 上午8:43寫道： > > Hello team. > > I've prepared metacam 1.2-11 package [1] with 3 BTS bugs closed. > > Please review and upload. > > [1] https://salsa.debian.org/pkg-security-team/metacam It would be great that if you can contact the upstream author and send back the patches afterward. SZ > > Regards, > Aleksey.
Re: dfwinreg: Request for review
Hi Hilko,
SZ Lin (林上智) 於 2018年10月31日 週三 上午11:03寫道：
>
> Hi Hilko,
>
> I've imported and packaged new version of dfwinreg, please review it
> before uploading when you're available.
>
> The new version of dfwinreg migrated from "construct" to "dtfabric" -
> which is not existed in Debian archive, and thus I packaged and
> uploaded "dtfabric" with python 3 only according to Debian Python
> policy [2].
>
> Main changes:
> - Import new upstream version
> - Drop python 2 support (I'm sure whether or not it could be an issue)
> - Update {Build-}Depends based on new upstream release
> - Other changes [3]
>
> Feel free to change/ revert/ modify anything, thanks.
I've prepared a team-upload for dfwinreg (versioned as 20180712-1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should cancel it or delay it longer.
SZ
>
> [1] https://salsa.debian.org/pkg-security-team/dfwinreg
> [2] https://www.debian.org/doc/packaging-manuals/python-policy/python3.html
> [3]
> https://salsa.debian.org/pkg-security-team/dfwinreg/blob/debian/master/debian/changelog
> --
>
> SZ Lin (林上智) , http://people.debian.org/~szlin
>
> Debian Developer
>
> 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9
dfwinreg: Request for review
Hi Hilko,
I've imported and packaged new version of dfwinreg, please review it
before uploading when you're available.
The new version of dfwinreg migrated from "construct" to "dtfabric" -
which is not existed in Debian archive, and thus I packaged and
uploaded "dtfabric" with python 3 only according to Debian Python
policy [2].
Main changes:
- Import new upstream version
- Drop python 2 support (I'm sure whether or not it could be an issue)
- Update {Build-}Depends based on new upstream release
- Other changes [3]
Feel free to change/ revert/ modify anything, thanks.
[1] https://salsa.debian.org/pkg-security-team/dfwinreg
[2] https://www.debian.org/doc/packaging-manuals/python-policy/python3.html
[3]
https://salsa.debian.org/pkg-security-team/dfwinreg/blob/debian/master/debian/changelog
--
SZ Lin (林上智) , http://people.debian.org/~szlin
Debian Developer
4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9
Re: New upstream source proposal for ssldump
Hi, Sophie Brun 於 2018年9月21日 週五 下午3:51寫道： > > Hi SZ, > Le 19/09/2018 à 12:00, SZ Lin (林上智) a écrit : > > > > I've done the packaging work with snapshot version from new upstream. > > Thanks > > > Since I am not quite familiar with OpenSSL 1.1 transition, please > > review it via the link below before putting into sid archive. > > > > https://salsa.debian.org/pkg-security-team/ssldump > > I'm not a specialist of openssl either. I had a look and it's ok for me. > Build is OK. > > I think you can upload. Thanks for the review. I've tweaked d/upstream/metadata and uploaded the package afterwards. Thank you for your time, again. SZ > > Thanks, > > Sophie > > > Thanks > > > > SZ > >
Re: New upstream source proposal for ssldump
Hi Sophie, Sophie Brun 於 2018年9月19日 週三 下午2:15寫道： > > Hi SZ, > > > [1] https://github.com/adulau/ssldump > > OK, no problem for me. > > Thanks > > Sophie I've done the packaging work with snapshot version from new upstream. Since I am not quite familiar with OpenSSL 1.1 transition, please review it via the link below before putting into sid archive. https://salsa.debian.org/pkg-security-team/ssldump Thanks SZ
Re: The license type of debianized files in "irpas"
Hi, Vince Mulhollon 於 2018年9月17日 週一 下午7:12寫道： > > > Dual License under the same license as the software itself "Phenoelit > License" or as the GPL whichever the reader would prefer. Thanks for your reply, the dual license "Phenoelit License" or "GPL-3" will be given to debianized files. SZ > > On Mon, Sep 17, 2018 at 4:56 AM SZ Lin (林上智) wrote: >> >> Hi Vince, >> >> I am updating DEP-5 copyright syntax with irpas, which was packaged by you. >> >> The original copyright in irpas didn't explicitly declare license of >> debian/* [1], could you tell me which license would you like to use? >> >> I would appreciate it if you could let me know. >> >> [1] >> https://salsa.debian.org/pkg-security-team/irpas/blob/debian/master/debian/copyright >> >> -- >> SZ
Re: Getting sandsifter in Debian
Hi, I've packaged draft package for sandsift [1] after discussing with upstream [2]. Please feel free to review or modify this, I will upload the package before the end of the week if there is no any issues. [1] https://salsa.debian.org/pkg-security-team/sandsift/ [2] https://github.com/rigred/sandsifter/issues/3 -- SZ Lin (林上智) , http://people.debian.org/~szlin Debian Developer 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9 SZ Lin (林上智) 於 2018年8月27日 週一 下午3:03寫道： > > Hi, > > It seems like the upstream [1] is not active for a while, the last > commit [2] is in Sep,2017. I would like to suggest replace the > upstream with this fork [3]. > > [1] https://github.com/xoreaxeaxeax/sandsifter > [2] > https://github.com/xoreaxeaxeax/sandsifter/commit/8375e6123d093629e3e4437d7903839fd0742c2a > [3] https://github.com/rigred/sandsifter > > -- > > SZ Lin (林上智) , http://people.debian.org/~szlin > > > shirish शिरीष 於 2018年8月16日 週四 下午2:48寫道： > > > > Dear all, > > > > First of all thank you for the whole team for keeping Debian as secure > > as it is the people on the team do to keep Debian free from > > controversy (at least from the security viewpoint) . > > > > Please CC me as I'm not subscribed to the mailing list, sorry. > > > > I just came upon sandsifter today. While I have done an RFP on it , > > could people have a look at it. > > > > It's being tracked as #906246 , thank you in advance. > > > > https://github.com/xoreaxeaxeax/sandsifter > > > > Also see https://www.youtube.com/watch?v=KrksBdWcZgQ which is a > > blackhat presentation given by the Developer. > > > > Could you all examine it and see if it's worth including in Debian, > > the only pre-requisite it asks for is already in Debian i.e. capstone. > > I dunno if it would be a good tool or not as I do not have the > > expertise to know whether the package 'phones home' or not, how > > dangerous or not dangerous the analysis would be. > > > > The only requirements are libcapstone3 and libcapstone-dev before > > compiling the python script (via make). The other odd thing seems to > > that the developer has mentioned to use 32-bit variation of the > > libcapstone3 and libcapstone-dev which at least IMHO would make it > > more resource intensive as it means it would be limited to only using > > 4 GiB of memory when it could use the whole 8-128 GiB memory depending > > upon the workstation properties but what do I know of these things. > > > > Looking forward to know. > > > > -- > > Regards, > > Shirish Agarwal शिरीष अग्रवाल > > My quotes in this email licensed under CC 3.0 > > http://creativecommons.org/licenses/by-nc/3.0/ > > http://flossexperiences.wordpress.com > > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 > >
Re: Getting sandsifter in Debian
Hi, It seems like the upstream [1] is not active for a while, the last commit [2] is in Sep,2017. I would like to suggest replace the upstream with this fork [3]. [1] https://github.com/xoreaxeaxeax/sandsifter [2] https://github.com/xoreaxeaxeax/sandsifter/commit/8375e6123d093629e3e4437d7903839fd0742c2a [3] https://github.com/rigred/sandsifter -- SZ Lin (林上智) , http://people.debian.org/~szlin shirish शिरीष 於 2018年8月16日 週四 下午2:48寫道： > > Dear all, > > First of all thank you for the whole team for keeping Debian as secure > as it is the people on the team do to keep Debian free from > controversy (at least from the security viewpoint) . > > Please CC me as I'm not subscribed to the mailing list, sorry. > > I just came upon sandsifter today. While I have done an RFP on it , > could people have a look at it. > > It's being tracked as #906246 , thank you in advance. > > https://github.com/xoreaxeaxeax/sandsifter > > Also see https://www.youtube.com/watch?v=KrksBdWcZgQ which is a > blackhat presentation given by the Developer. > > Could you all examine it and see if it's worth including in Debian, > the only pre-requisite it asks for is already in Debian i.e. capstone. > I dunno if it would be a good tool or not as I do not have the > expertise to know whether the package 'phones home' or not, how > dangerous or not dangerous the analysis would be. > > The only requirements are libcapstone3 and libcapstone-dev before > compiling the python script (via make). The other odd thing seems to > that the developer has mentioned to use 32-bit variation of the > libcapstone3 and libcapstone-dev which at least IMHO would make it > more resource intensive as it means it would be limited to only using > 4 GiB of memory when it could use the whole 8-128 GiB memory depending > upon the workstation properties but what do I know of these things. > > Looking forward to know. > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0/ > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 >
Re: Getting sandsifter in Debian
Hi, If no one has any objections, I would like to package this tool and mark as a team maintained package afterwards. -- SZ Lin (林上智) , http://people.debian.org/~szlin 4096R/ 178F 8338 B314 01E3 04FC 44BA A959 B38A 9561 F3F9 2018-08-16 14:47 GMT+08:00 shirish शिरीष : > Dear all, > > First of all thank you for the whole team for keeping Debian as secure > as it is the people on the team do to keep Debian free from > controversy (at least from the security viewpoint) . > > Please CC me as I'm not subscribed to the mailing list, sorry. > > I just came upon sandsifter today. While I have done an RFP on it , > could people have a look at it. > > It's being tracked as #906246 , thank you in advance. > > https://github.com/xoreaxeaxeax/sandsifter > > Also see https://www.youtube.com/watch?v=KrksBdWcZgQ which is a > blackhat presentation given by the Developer. > > Could you all examine it and see if it's worth including in Debian, > the only pre-requisite it asks for is already in Debian i.e. capstone. > I dunno if it would be a good tool or not as I do not have the > expertise to know whether the package 'phones home' or not, how > dangerous or not dangerous the analysis would be. > > The only requirements are libcapstone3 and libcapstone-dev before > compiling the python script (via make). The other odd thing seems to > that the developer has mentioned to use 32-bit variation of the > libcapstone3 and libcapstone-dev which at least IMHO would make it > more resource intensive as it means it would be limited to only using > 4 GiB of memory when it could use the whole 8-128 GiB memory depending > upon the workstation properties but what do I know of these things. > > Looking forward to know. > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0/ > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 >
