Re: Thinking about a "jessie and a half" release
2016-07-05 7:43 GMT-03:00 Jose R R <jose@metztli-it.com>: > > Why would you call it "Jessie + 1/2"? Wouldn't it be a better idea > Well IBM set a precedent for that: OS/2. > Accordingly, Jessie BP could be called Jessie/2 ;-) Well, that would be a half Jessie, not Jessie and a half, right? We could use 3Jessie/2 or Jessie3/2, or maybe not. Mark Brown > We're getting to the point where there's a fairly pressing need for > arm64 - the more useful hardware is starting to get a wider distribution > and we don't really have anything for people who want to run Debian > that gets them a supported system with an upgrade path. > We have Debian Stretch, which is what i recommend to anybody who wants do install Debian as a desktop. I understand the difference of running Debian Testing and Debian Stable with some backported packages, but is it really worth it? Shouldn't we discuss more the usability of Testing as a solid release, or maybe start doing a stable release and another release kinda like Testing but with more stability guarantees? I'm not really sure, but i think opensuse has a model like that. I use debian for a considerable amount of time now, but just started interacting with the community recently, having installed debian to a lot of new users on installfests over the years, one of the most common problems i found out for novice Debian users is that they don't really know how Debian releases works and thinks using stable in their laptop bought last year is a good idea, then i always end up having a conversation where they're needing help with problems related to using stable, i have to explain things like: why their performance is crap, why they can't see youtube html5 videos on iceweasel version lastversion-4, why they can't install softwares like steam (wheezy was a hard one on this)* and how the testing stability is the same, or better, than of the other distros they used to use. They always end up using Debian Testing, knowing that the main risk comes when the unfreeze happens and that while the freeze is rolling they will have a more stable debian (compared to when unfreezed). *these are just some of the various conversations i've had. Unfortunately i' not attending DebConf, but it is a great opportunity to discuss things like this there, maybe even form a team and work on policies changes for this "new testing" release, if i'm not dreaming too big. Samuel Henrique O. P. [samueloph]
Bug#876944: jessie-pu: package bwm-ng/0.6-3.1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu This is a small change on d/rules passing "--without-libstatgrab" (as advised by upstream on a duplicate bug report[1]) to fix #855215[2]. I confirmed the bug on Jessie, confirmed the fix on jessie-bpo (the 0.6.1 release was fixed), and confirmed this fix attached on jessie at 3 different machines (mine and the two people cited on changelog), it all looks good. No regressions. I also pushed the fix on git[3]. As i'm not a DD, Terceiro will sponsor my upload. There's also more these bugreports[4][5][6]. [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746014#15 [2]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855215 [3] https://anonscm.debian.org/git/collab-maint/bwm-ng.git/log/?h=debian/jessie [4]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826983 [5]https://bugs.launchpad.net/ubuntu/+source/bwm-ng/+bug/1502593 [6]https://bugs.launchpad.net/ubuntu/+source/bwm-ng/+bug/1719156 -- Samuel Henrique bwm-ng_0.6-3.1+deb8u1.debdiff Description: Binary data
Bug#876944: jessie-pu: package bwm-ng/0.6-3.1
2017-11-18 17:03 GMT-02:00 Adam D. Barratt <a...@adam-barratt.org.uk>: > On Wed, 2017-09-27 at 00:53 -0300, Samuel Henrique wrote: > > This is a small change on d/rules passing "--without-libstatgrab" > > (as advised by upstream on a duplicate bug report[1]) to fix > > #855215[2]. > > > > While I assume the end result is sane, passing both --with-libstatgrab > and --without-libstatgrab to the same configure invocation is at best > confusing... > Thanks for catching that, it was my mistake. There's an updated debdiff attached, already pushed to git. -- Samuel Henrique bwm-ng_0.6-3.1+deb8u1.debdiff Description: Binary data
Bug#926426: unblock: python-smoke-zephyr/1.4.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I'm asking for the unblock of python-smoke-zephyr because a critical bug was solved upstream. This bug was detected in the past and me and upstream thought it was fixed already[0], then after it was reported again recently[1] we found out that the problem still persisted. This time I first tried to fix the problem by uploading 1.4.0-2, and while it was on Unstable I think somebody else filled an unblock request and it was granted, but before this version hit testing I uploaded the correct fix (1.4.1-1) to unstable, that's why you can see two changelog entries on the debdiff. Thanks [0]https://github.com/zeroSteiner/smoke-zephyr/issues/4 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925208 -- Samuel Henrique python-smoke-zephyr.debdiff Description: Binary data
Bug#926681: unblock: acme-tiny/1:4.0.4-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I'm asking for the unblock of acme-tiny because a critical bug was solved upstream. I needed to package the last upstream release to address the following bug: acme-tiny: Please update to ACMEv2 API #924393 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924393 I didn't upload to unstable yet as I'm still waiting for the ack from the other members of the LetsEncrypt team and I also understand that the debdiff is big so it's better to wait for the release team's ack as well. Here is why I believe this last release is at least as stable as the previous one: It is dated 17/05/2018, this is almost one year since it was released, considering the package is also available on pip, I assume a good amount of people are already running the latest release for some time now. Also, a good amount of open issues and PRs on Github are dated from before the latest release, there are no indicators in there this release may introduce new problems. Thanks, -- Samuel Henrique acme-tiny.debdiff Description: Binary data
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I'm asking for the unblock of ruby-airbrussh because a critical bug was solved in the last upload. The bug is related to the package throwing an exception when dealing with non UTF-8 characters coming from SSH. I decided to upload the latest release instead of patching the previous release because the only functionality change of the latest release is this one, all the other changes can't possibly affect the package, and in this case it's simpler to have the latest release then to patch it and possibly induce the users to think that this problem is not fixed: * Files changed that fix this problem: - lib/airbrussh/console.rb * Other files changed, not needed to fix the problem, can't break anything and makes the package better: - test/airbrussh/console_test.rb (it's a new test case for this problem) * Other files changed, not needed to fix the problem, can't break anything and does not make any difference on the package: - appveyor.yml - CHANGELOG.md - lib/airbrussh/version.rb - LICENSE.txt - .travis.yml As you can see, all of the files in this case are metadata files. I didn't open a RC bug on BTS because I'm assuming it's not necessary as we already have the upstream one and the fix is already on Unstable. This is the bug that was fixed in this new release: https://github.com/mattbrictson/airbrussh/issues/120 PR + some discussion: https://github.com/mattbrictson/airbrussh/pull/121 Special attention to the fact that the bug was noticed while using capistrano, which depends on this package and was the only reason I packaged it. Thanks, -- Samuel Henrique ruby-airbrussh.debdiff Description: Binary data
Bug#926681: unblock: acme-tiny/1:4.0.4-1
Hi all, Uploaded to the DELAYED queue with 7 days delay. On Sun, 12 May 2019 at 14:58, Samuel Henrique wrote: > Hello Niels, > > Sorry for the delay on this. >> > > No worries, I know you've been doing lots of work during the freeze, and I > noticed that you also proactively unblocked some of my packages, thanks for > that. > > >> Please go ahead with the upload and remove the moreinfo tag once it is >> in unstable and ready to be unblocked. >> > > Unfortunately the package was removed from testing 5 days ago [2019-05-08], > the freeze policy says that "packages not in testing can not migrate to > testing¨. > > Is this case different because the fix was ready before the package was > removed? > > Harlan and Sebastien: > I think I'm not in the salsa team yet, can you please take a look at this > as well, so I would rather have the team's acknowledgment, this seems like > an important package for you. > Thanks, -- Samuel Henrique
Bug#928994: unblock: t50/5.8.3-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hello, I'm asking for the unblock of t50 because a critical bug was solved in the last upload. The change consists of an update to an already existing quilt patch, and it is removing architecture specific code from the Makefile. Bug report: #928991 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928991 Thanks, -- Samuel Henrique t50.debdiff Description: Binary data
Bug#926681: Fwd: Bug#926681: unblock: acme-tiny/1:4.0.4-1
Control: tags -1 - moreinfo
Bug#926681: unblock: acme-tiny/1:4.0.4-1
Hello Niels, Sorry for the delay on this. > No worries, I know you've been doing lots of work during the freeze, and I noticed that you also proactively unblocked some of my packages, thanks for that. > Please go ahead with the upload and remove the moreinfo tag once it is > in unstable and ready to be unblocked. > Unfortunately the package was removed from testing 5 days ago [2019-05-08], the freeze policy says that "packages not in testing can not migrate to testing¨. Is this case different because the fix was ready before the package was removed? Harlan and Sebastien: I think I'm not in the salsa team yet, can you please take a look at this as well, so I would rather have the team's acknowledgment, this seems like an important package for you. Thanks, -- Samuel Henrique
Bug#926681: unblock: acme-tiny/1:4.0.4-1
I do understand that this is a new upstream release but it should be unblocked because it's a 198 line python script. If we don't fix this, then acme-tiny will have to be removed from Buster. @LetsEncrypt team, do you have any words on this? -- Samuel Henrique
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Control: tags -1 - moreinfo Hello Paul, Control: tags -1 moreinfo > I removed the moreinfo tag as I assume now you will have enough information to make a judgement call on this one, feel free to tell me if I should not have done so. > > I'm asking for the unblock of ruby-airbrussh > > because a critical bug was solved in the last upload. > > > > The bug is related to the package throwing an exception when dealing > > with non UTF-8 characters coming from SSH. > > Can you elaborate a bit why the severity? (Would have been nice to have > that description in the bug you didn't file). Looking at the upstream > bug, it may just be confusing to the user and ugly of course as rsync > was said to keep on running. Is rsync in Debian broken in the same way? > So, the main problem here is that when using capistrano (a deployment tool), the user will think that the deployment failed because ruby-airbrussh will have problems with non UTF-8 characters coming from SSH`ed rsync. I do not have reasons to think that rsync is broken in the same way, as the main problem here is misguiding the user into thinking that there is something wrong with the deployment. Capistrano is used for production critical pipelines at some companies. In summary, the deployment will probably occur normally, but the only guarantee of that would be the user having to manually debug the error and checking whether it succeeded or not under the hood. > > I decided to upload the latest release instead of patching the previous > > release > > Which still means review work by us. We do have quite some unblocks > coming in this last freeze moment. > I can see you have lots of work to do, so if you feel like this should not be fixed for the first Buster release, I will try to address this with stable-updates, if you think that's acceptable. With my maintainer's hat on I say that it's important to fix this before releasing Buster, and the changes are very trivial, but I do acknowledge that the best person to make the call here is someone from the release team, so whatever you say I'm fine with it. -- Samuel Henrique
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Thanks for your help Paul :) I'm attaching a debdiff for 1.3.2-1+deb10u1, release team please advise whether that's acceptable or not (please read discussion on the bugreport), Regards, -- Samuel Henrique ruby-airbrussh_1.3.2-1+deb10u1.debdiff Description: Binary data
Bug#935137: buster-pu: package acme-tiny/4.0.4-1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu The acme v2 protocol is gonna stop accepting plain GET requests as of November 1st, this will make buster's acme-tiny stop working. I applied an upstream patch to fix it, it's just a switch to use signed requests, support was already in there. More detailed information: https://github.com/diafygi/acme-tiny/issues/226 https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unauthenticated-resource-gets/74380 This update needs to be part of the first point release, I will upload as soon as I receive confirmation from the release team. Thanks, -- Samuel Henrique acme-tiny_4.0.4-1+deb10u1.debdiff Description: Binary data
Bug#935137:
I forgot to add the patch to d/series, you'll find the updated debdiff attached. -- Samuel Henrique acme-tiny_4.0.4-1+deb10u1.debdiff Description: Binary data
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Hello Adam, It certainly can't be 1.3.2-1+deb10u1, as that version number is higher > than the package in unstable. Either one would need to go with 1.3.1- > 2+deb10u1 with just the bug fix applied, or 1.3.2-1~deb10u1 with a > "backports-style" changelog containing both 1.3.2-1 and then the stable > update. In either case we would need a debdiff that reflects the chosen > approach. > > One thing that will need to be fixed in unstable first either way: > > Not built on buildd: arch all binaries uploaded by samueloph > > As per the d-d-a announcement, that will need a new source upload to > unstable to resolve, as arch:all can't be usefully binNMUed. > I just uploaded 1.3.3-1 (source-only) to unstable, can I just wait until it migrates to testing and then go with "1.3.2-1+deb10u1" ? If so, I will remove the "moreinfo" tag when it the package migrates to Testing (in 2 days) and we can use the latest debdiff on this thread. Thanks, -- Samuel Henrique
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Hello Adam, Thanks for your patience and explanation, here's the debdiff with the solution I picked, I backported the fix to 1.3.1-2, the version is 1.3.1-2+deb10u1 and I will need to wait until 1.3.3-1 hits testing*, which is fine (2 days), to upload it. * because the current version in testing is the same as in stable, and the version in testing needs to be higher/bug fixed in there as well. Regards, -- Samuel Henrique ruby-airbrussh_1.3.1-2+deb10u1.debdiff Description: Binary data
Bug#935137:
Hello, > I forgot to add the patch to d/series, you'll find the updated debdiff > > attached. > > Please go ahead. > acme-tiny_4.0.4-1+deb10u1_source.changes ACCEPTED into proposed-updates->stable-new -- Samuel Henrique
Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Capistrano is a widely used tool for deployments, one of the steps of a deployment is to remove the old releases, this consists in removing the last Nth releases' folders. Recently a bug has been found when one had too many releases, as they are removed with the "rm" command, having too many arguments on the command triggers the "argument list too long" error. The fix[0] is a small change that splices the arguments in bulks of 100. Note that the commit is also changing more things, but they're an extra test and a changelog entry, thus I decided it would be better to add the whole commit to the package. In order for the fix to be applied, another commit[1][2] had to be applied as well so there's no conflict and need to update the fix commit. I understand an alternative would be to adapt the fix in some way that this commit is not needed, I see the chosen approach as more stable and reliable as it's the upstream's code that was well tested, besides this extra commit being a small change. In summary I believe this is a problem that should be fixed in stable and the approach taken was consistent to our stable philosophy. Let's make buster even more rock solid. Thanks, [0] https://github.com/capistrano/capistrano/pull/2027/commits/89a77085780fbcae9b21d0aa10001969172cfa0a#diff-aa4465f31474e46370f8f1f204f7d51eR171 [1]https://github.com/capistrano/capistrano/pull/1995 [2] https://github.com/capistrano/capistrano/pull/1995/commits/ad9c0a455516426e3c634e9c9925b9cfd77d5108 -- Samuel Henrique capistrano_3.11.0-3+deb10u1.debdiff Description: Binary data
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Hello, Uploaded: ruby-airbrussh_1.3.1-2+deb10u1_source.changes ACCEPTED into proposed-updates->stable-new Thanks for your work and help Adam and Paul, -- Samuel Henrique
Bug#930795: unblock: ruby-airbrussh/1.3.2-1
Control: tags -1 - moreinfo Removing moreinfo tag as 1.3.3-1 is on testing and the debdiff for 1.3.1-2+deb10u1 is attached in the previous email, Thanks, -- Samuel Henrique
Bug#939354: buster-pu: package capistrano/3.11.0-3+deb10u1
Thanks Julien, > Looks ok, go ahead. It would have been helpful to note that and when > this was fixed in sid, since there's no corresponding debian bug. I changed d/changelog to mention that this was fixed in upstream's 3.11.1 sid and testing currently have 3.11.2, I hope that helps clear it up. Uploaded. capistrano_3.11.0-3+deb10u1_source.changes ACCEPTED into proposed-updates->stable-new -- Samuel Henrique
request to remove "-updates" repository
Hello Team, I know I'm risking being unaware of something that invalidates this request, so please also consider this a request for clarifications if it's the case. While discussing #954460 [0] with Cyril, I decided to give it a try to update the debian-reference section which mentions the "-updates" repository[1], to make it more informative on what it's about, and noticed that the reference does not mention that this repository is enabled by default, currently putting it side-by-side with the backports repository (which I consider a bad thing). So I started thinking about how the whole section should be rewritten to make it more clear how Debian deals with point releases and stable updates, and I realized that "-updates" could actually just be removed totally and updates could be pushed to the main repository instead, thus reducing the complexity and helping with the user confusion about what is "-updates" and how point releases works[2]. Is there any gotcha that I'm missing here? An user which doesn't want to have "-updates" merged into the main repository could accomplish the same by just not updating their system, which is something nobody should do anyway[3] but the behavior would still be there. Regards, [0] remove mentions of "volatile" repo from sources.list: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954460 [1] https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports [2] unfortunately it's still very common for users to not understand point releases are just the transition from -updates to the main repo, and that considering -updates is already enabled, it makes no difference as long as the system is updated. [3] such cases would also be more clear, because instead of the situation being "my system is updated (false), I just don't use -updates" to "I haven't updated the system since the last point release" -- Samuel Henrique
Re: request to remove "-updates" repository
Hello Adam, On Sun, 5 Apr 2020 at 20:15, Adam D. Barratt wrote: > > On Sun, 2020-04-05 at 19:51 +0100, Samuel Henrique wrote: > > For the scope of "stable-updates" only then, would you say it makes > > sense to just use "stable" instead, for the reasons I mentioned? > > What do you say would be the negative impact of that (if any), since > > the repository is already enabled by default and not using it is > > equivalent to not updating the system until a point release gets out? > > Changing "stable" only happens at point releases, since it requires > (amongst other things) combined GPG signatures from the FTP Team and > Release Team. It's also a multiple hour process, involving both ftp and > release teams together with the press and images teams, updated > installers and so on. I wasn't aware of this whole process happening for a point release, this puts things in perspective. > Removing stable-updates would mean that the only way that some changes > - for instance, timezone updates, clamav updates, critical regressions > introduced in a point release but not noticed until afterwards - would > reach users would be for us to perform a point release or for the users > to consume proposed-updates. I'm not convinced that either of those is > a useful alternative. Agreed, my proposal does not works with the current workflow. I'm interested in this process, is there any documentation you recommend me to understand the under-the-hood details of this? Thanks for the clarifications. -- Samuel Henrique
Re: request to remove "-updates" repository
Hello Adam, On Sun, 5 Apr 2020 at 19:37, Adam D. Barratt wrote: > > On Sun, 2020-04-05 at 19:03 +0100, Samuel Henrique wrote: > > I know I'm risking being unaware of something that invalidates this > > request, so please also consider this a request for clarifications if > > it's the case. > > > > While discussing #954460 [0] with Cyril, I decided to give it a try > > to update the debian-reference section which mentions the "-updates" > > repository[1], to make it more informative on what it's about, and > > noticed that the reference does not mention that this repository is > > enabled by default, currently putting it side-by-side with the > > backports repository (which I consider a bad thing). > > By -updates, I assume you mean stable-updates. That' s right > > So I started thinking about how the whole section should be rewritten > > to make it more clear how Debian deals with point releases and stable > > updates, and I realized that "-updates" could actually just be > > removed totally and updates could be pushed to the main repository > > instead, thus reducing the complexity and helping with the user > > confusion about what is "-updates" and how point releases works[2]. > > What do you mean by "the main repository" here? I meant to say the stable (or $codename) release's repository: deb http://deb.debian.org/debian/ buster main > The entire point of stable-updates is that it contains packages that > will be in a point release (and thus are already in proposed-updates) > but that for some reason have been identified as important enough to be > offered to users before the point release occurs. > > How would you see that function being fulfilled if the stable-updates > suites were removed? The idea was to use the release repository directly instead, since "stable-updates" is enabled by default and not using it would be equivalent to just not updating the system, so pushing the updates to "deb http://deb.debian.org/debian/ buster main" instead. > > [2] unfortunately it's still very common for users to not understand > > point releases are just the transition from -updates to the main > > repo, and that considering -updates is already enabled, it makes no > > difference as long as the system is updated. > > Point releases move packages from proposed-updates to stable, not from > stable-updates. Packages in stable-updates never move to any other > suite. Hmm, that was a misconception of mine, I thought everything was going to "stable-updates" automatically. This changes things a bit since point releases then means actual changes even for somebody who just updated the system right before so. For the scope of "stable-updates" only then, would you say it makes sense to just use "stable" instead, for the reasons I mentioned? What do you say would be the negative impact of that (if any), since the repository is already enabled by default and not using it is equivalent to not updating the system until a point release gets out? Thanks, -- Samuel Henrique
Re: Bug#954460: remove mentions of "volatile" repo from sources.list
Hello Cyril, > I'm wondering whether we should have a pointer to some documentation > that would explain what that is. I seem to have this in my web browser > history; > > https://lists.debian.org/debian-devel-announce/2011/03/msg00010.html > > but there might better places, like this one? > > https://wiki.debian.org/StableUpdates I like your suggestion, this is a good opportunity to link some documentation explaining a little bit of how updates are done for stable releases. I would be reluctant to add any reference to the wiki at all because it has some ip addresses blacklisted and I remember having multiple cases of Brazilian users being unable to access it because they were under a blacklisted shared public ip. The debian-reference[0] seems like a good thing to point to instead, although not explaining "-updates" as well as the wiki, maybe that could be changed, What are your thoughts? [0]https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports -- Samuel Henrique
Re: Bug#954460: remove mentions of "volatile" repo from sources.list
Hello Cyril, > Would the following look like some reasonable middle ground? > > 1. Link to the wiki for the time being, getting rid of volatile, and > pointing users without any IP restrictions to some documentation. > 2. Get the ball rolling to update the devref. > 3. Switch the link from the wiki to the devref once the latter is > updated. Yes, this seems like a good way to go, I will be able to work on this during the weekend, to update the patch and submit the devref MR, if you'd like to do it yourself before that, feel free to go ahead. Thanks, -- Samuel Henrique
Bug#969009: transition: sleuthkit
Hello Sebastian, cc'in Hilko (who can shout if I'm saying something wrong here) I'm helping Francisco with this transition and so I figure I should chime in, > pytsk build depends on libtsk-dev but the binaries don't depend on > libtsk13. Is that expected? Yes, pytsk bundles libtsk and so it ends up in the "Built-Using" field instead of a dependency, I confirmed that the binaries don't get linked to it. It's my assumption that in such cases there is no need to list the package in the transition, would say this is the correct approach? We will perform a new upload of the package nonetheless just so our users can get the fresh stuff. > The tracker only lists libguestfs as needing a rebuild. So there won't > be any actions required from our side. Feel free to go ahead with the > upload to unstable. I'm gonna wait for you reply to proceed with sponsoring the upload just to confirm we're on the same page, Thanks! -- Samuel Henrique
Bug#969009: transition: sleuthkit
Hello Richard, > The libguestfs FTBFS thing is caused by a bug in binutils > (not OCaml or libguestfs). See: > > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/3YRZ5TJK7PTYDYHUDOYC5HFWKZPA7KIJ/ > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4d8ee860737005517be588f4771c358593fa421c Thank you very much for providing the upstream link to the fix, we currently have quite a few bugs for this issue against binutils, I'm forwarding this email to them. Regards, -- Samuel Henrique
Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1
Hello, I believe you picked the wrong bug id, could you double check that, please? Thanks
Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu A backported upstream patch [0] is required to fix #940284 [1] on nmap; Bug title: autogeneration of ssl key in ssl server mode of ncat is broken The issue itself is well described in both BTS [1] and the upstream bug report [2], but the summary of it is that the openssl shipped with Buster requires a key with minimum size of 2048b, while nmap 7.70 generates one sized 1024b. This has been fixed in 7.80 (which is the version on Testing right now). The debdiff is attached to this email, Thanks, [0] https://github.com/nmap/nmap/commit/25db5fbb0d8fb88b6e7f4f298c862cd05ed0f8b1 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940284 [2] https://github.com/nmap/nmap/pull/1310 -- Samuel Henrique nmap_7.70+dfsg1-6+deb10u1.debdiff Description: Binary data
Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1
> Please go ahead. Thank you Adam, nmap_7.70+dfsg1-6+deb10u1_source.changes ACCEPTED into proposed-updates->stable-new Regards, -- Samuel Henrique
Bug#900837: update on mass-rebuild of packages for reproducible builds
Hello Vagrant, On Fri, 4 Dec 2020 at 02:48, Vagrant Cascadian < vagr...@reproducible-builds.org> wrote: > On 2019-03-05, Holger Levsen wrote: > > I ran Chris's script again on coccia, with the result that currently > > 6084 source packages in the archive need a rebuild for reproducible > > builds, as they were built with an old dpkg version not producing > > .buildinfo files. > > I ran it just now, and we're down to 3433! Still a ways to go, but > getting there... > > Updated list attached. > That's great news, I'd like to help by making sure none of my packages are on this list, I can do the search myself but I'd like to ask for a list by maintainer name (if that's easy for you to generate). Mass bug filling would also help but I'm sure that was considered already. Thanks! -- Samuel Henrique
Bug#989918: unblock: aeskeyfind/1:1.0-11
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: samuel...@debian.org Severity: normal Please unblock package aeskeyfind [ Reason ] The recent introduction of integration tests, thanks to Jan Gru < j4n...@gmail.com> uncovered two critical issues with aeskeyfind: 1. A somewhat recent regression caused by compiler's change and aeskeyfind's code with undefined behavior 2. Failure to retrieve AES keys on a non-corrupted memory dump for archs arm64, armhf and ppc64el (integration tests only pass for amd64 and i386). Problem 1 is fixed by a patch provided by Adrian Bunk and problem 2 is mitigated by disabling the other archs (restricting it to amd64 and i386). More details at the bugreport: https://bugs.debian.org/989179 [ Impact ] aeskeyfind will fail to fulfill its only purpose of finding AES keys on memory dumps. [ Tests ] The new integration tests allowed us to identify the issues in the first place. [ Risks ] Since aeskeyfind is also used to recover AES keys out of corrupted memory dumps, it **could** be possible that our fix for the non-corrupted scenario broke the detection for corrupted dumps. I'm very confident that this cannot be the case because of the way aeskeyfind looks for keys; without the fix it was still possible to retrieve the key by making use of the threshold (-t 50) parameter (which tweaks the heuristics of the algorithm). The fix allows us to use the default threshold value (-t 10) which means the algorithm gets the key with more confidence. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock aeskeyfind/1:1.0-11 aeskeyfind_1.0-11.debdiff Description: Binary data
Bug#989860: unblock: ieee-data/20210605.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: samuel...@debian.org Severity: normal Please unblock package ieee-data [ Reason ] The package ieee-data provides the mapping between MAC address prefixes and vendors and a script to update its data. We should always try to provide the most up-to-date data out-of-the-box to our users. I have prepared a new release for buster, with the updated data, adding myself as an Uploader and fixing an error in d/copyright: d/changelog: * Update all txt and cvs files with data from Jun 05 * Add myself as an uploader * d/copyright: Remove duplicate globbing patterns [ Impact ] We will ship outdated data in the package and the users will have to manually update it, thus defeating half of the purpose of the package (the "other half" purpose is to ship a script to update this data). The data being updated in this upload should be kept up-to-date even after bullseye gets released, so it's very likely that I'll send bullseye-pu at some point in the future as well. The data shipped by ieee-data is also used by other packages, and lintian tries to enforce that[0]. [ Tests ] The files were downloaded with the script shipped in the package and I didn't spot any corruption of data. [ Risks ] Risk 1) To have corrupted data in the files. Easy to revert. Could also be triggered by the package's own script to update its files. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] The diff is too big to be attached here. Here is the list of commits by order of importance: https://salsa.debian.org/debian/ieee-data/-/commit/585a84f746390c3d10a8d26165df9290e095ea01 https://salsa.debian.org/debian/ieee-data/-/commit/71c6bc5648bcbbdc78c05b6154d4bc77d533554f https://salsa.debian.org/debian/ieee-data/-/commit/ad6729aa8334d2eca48d463c85a144aaaea5e15d https://salsa.debian.org/debian/ieee-data/-/commit/151e027733524eafaa7e42bc69a80d54c178ec7a * I just realized there's a typo on "cvs", it should be "csv", but it's too late now. unblock ieee-data/20210605.1 [0] https://lintian.debian.org/tags/package-installs-ieee-data -- Samuel Henrique
Bug#989502: stretch-pu: package ieee-data/20160613.1+deb9u1+nmu1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: stretch X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] I'd like to perform an oldstable NMU upload in order to fix #908623 and #932711: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908623 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932711 The ieee-data package ships a script (update-ieee-data) which queries ieee.org to download the most recent dataset and save it to /var/lib/ieee-data/ This script broke for stretch and earlier releases at the end of 2018 and I'd like to fix it by pointing the script to the correct URL (which is the one used on buster and bullseye). [ Impact ] This is the only functionality of the script, so it will stay fully broken. [ Tests ] Manually tested and confirmed that the correct data got saved to /var/lib/ieee-data/ [ Risks ] Since the script is not working anymore, the only risk involved is related to getting the wrong data and corrupting the existing contents of /var/lib/ieee-data/. The probability of this happening is lowered due to the script changing to an URL from the same domain, connecting through HTTPS, and considering this is the same URL used for buster and bullseye. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Points the script to the new URLs. [ Other info ] The maintainer acked an NMU on #932711 I'm also trying to reach out to Luciano so I can help on the maintenance of the package and update its dataset for bullseye. -- Samuel Henrique ieee-data_20160613.1+deb9u1+nmu1.debdiff Description: Binary data
Bug#985683: unblock: powerline/2.8.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package powerline I'd like to update powerline to the latest release, it's a minor version bump, with all the changes being fair for a minor bump. powerline is a non-key package and a mature software at this point, our users will benefit from a considerable amount of bugfixes which would be too much work to port individually. I have verified all commits since the previous release and everything looks good. Note that powerline is only blocked because it doesn't have autopkgtest, but upstream does have good automated testing on their side. [ Reason ] * Use `--no-optional-locks` to reduce conflicts with other git editors * Fixes elapsed time that is provided with a ',' instead of a '.' * Render cpu_load_percent segment even when psutil returns 0.0 * Shifted away from (abandoned) Yahoo API to OpenWeatherMap * Prefer Python 3 in the Vim plugin * Fixed getcwd for tmux * Fix escaping of sh specific characters in tmux * Use updated i3ipc syntax in i3 segments/listers [ Impact ] Missing the fixes described above. [ Tests ] I use powerline daily and I have not found any issues with the latest release. Upstream also runs a lot of automated tests against different environments and found no regressions. https://travis-ci.org/github/powerline/powerline/builds/760903189 [ Risks ] non-key package The new release is mostly about fixinf existing problems, though there are a few functionality additions, all the commits were verified by me and can be seen here: https://github.com/powerline/powerline/compare/d137a88...2.8.2 powerline is a mature software at this point, and this being a minor release plus all the automated tests give me confidence we should ship this release to our users. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock powerline/2.8.2-1
Bug#994107: bullseye-pu: package mtr/0.94-1+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] There's a regression in Debian's packaging of mtr 0.94 in which json support is missing due to a change in upstream. It now requires the package to be compiled with jansson for it to work. This issue only affects bullseye as of now. [ Impact ] Failure when trying to use the --json option: $ mtr --json debian.org mtr: unrecognized option '--json' [ Tests ] Manually confirmed that the fix, currently in testing, is working both with --json and without it. [ Risks ] The only risk of regression relies on mtr breaking somewhere else due to this library being available at compilation time. I consider this extremely unlikely. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Addition of libjansson-dev as a build-dep. [ Other info ] https://bugs.debian.org/986534 -- Samuel Henrique mtr_0.94-1+deb11u1.debdiff Description: Binary data
Bug#994111: bullseye-pu: package shellcheck/0.7.1-1+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] The manpage of shellcheck has been broken on Debian for a while now, at least since oldstable/buster. The issue is that the long form of the options are having its double dashes corrupted by pandoc due to the way the manpage is generated. Eg.: option "--list-optional" becomes "–list-optional" [ Impact ] All the long options in the manpage are wrong and lead the user to have errors like: $ shellcheck –list-optional –list-optional: –list-optional: openBinaryFile: does not exist (No such file or directory) [ Tests ] Confirmed the fix by checking: https://manpages.debian.org/unstable/shellcheck/shellcheck.1.en.html Broken version here: https://manpages.debian.org/bullseye/shellcheck/shellcheck.1.en.html [ Risks ] No risks as I checked the whole manpage and there were no side effects. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Manpage is now generated with an extra option "-f markdown-smart" to explicitly set the format of the input file. [ Other info ] https://bugs.debian.org/985003 https://bugs.debian.org/918555 The package is currently blocked from migrating to testing due to an autopkgtest issue not exactly related to shellcheck, more details at the initramfs-tools bug report: https://bugs.debian.org/992798 Thank you, -- Samuel Henrique shellcheck_0.7.1-1+deb11u1.debdiff Description: Binary data
Bug#995075: bullseye-pu: package rsync/3.2.3-4+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] I would like to update rsync based on issues we detected after releasing bullseye and on upstream commits done after 3.2.3 was released. Most of the changes are fixing regressions that showed up between the version we ship in buster and the one we ship in bullseye. The ones who don't fit into this category are either improvements to the docs or bugs that existed before the version we have in buster. [ Impact ] There are multiple changes here, but the most impactful ones are fixing regressions, thus the impact being that Debian users updating from buster to bullseye could have unexpected breakages when using rsync. [ Tests ] Some of the changes also contain their own tests, for the other ones I manually tested to confirm they're working fine (most of the bug reports from upstream had instructions on how to reproduce) [ Risks ] The risks are somewhat low as the changes were tested and they seem well contained in their domains. As in, any possible breakages would only affect those use cases and not extend to broader ones. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] 1) Re-add upstream patch for --copy-devices, the --write-devices option is not fully equivalent (closes: #992215): https://bugs.debian.org/992215 This change will require me to update the release notes, which I'll do after the upload goes through: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#rsync-parameter-deprecation 2) d/rsync.docs: Add NEWS.md file (previously named NEWS) (closes: #993697): Simple fix to a regression that happened when upstream renamed the file: https://bugs.debian.org/993697 3) d/p/fix_delay_updates.patch: New patch from upstream (closes: #992231): Pick upstream patch to fix a regression in the parameter --fix-delay, the patch has a low footprint and comes with a unit test: https://bugs.debian.org/992231 https://github.com/WayneD/rsync/issues/192 4) d/p/fix_mkpath.patch: New upstream patch to fix an edge case on --mkpath. Fix an issue when using rsync with mkpath when the folder exists and the file has a different name: https://github.com/WayneD/rsync/issues/96 5) d/p/fix_rsync-ssl_RSYNC_SSL_CERT_feature: New upstream patch to fix an edge case on rsync-ssl. Fix a shellscript's simple mistake: https://github.com/WayneD/rsync/commit/592c6bc3e5e93f36c2fdc0a491a9fb43a41cf688 6) d/p/fix_sparse_inplace.patch: New upstream patch to fix --sparse + --inplace options. Fix issue that happens when both --sparse and --inplace are used together: https://github.com/WayneD/rsync/issues/114 7) d/p/manpage_upstream_fixes.patch: Import multiple upstream patches to fix manpage. I merged multiple manpage fixes from upstream into a single patch, they should all be simple enough that no further details are needed. 8) d/p/update_rrsync_options.patch: New upstream patch to update rrsync options. rrsync was a bit outdated with regards to the options it supported, this simple patch updates it by adding support for the parameters mkpath, msgs2stderr and no-msgs2stderr. Note that the patch only lets rrsync receive those parameters, the support itself for those are already implemented in rsync. [ Other info ] Due to the nature of change number 1, I would appreciate it if we could ship this in time for 11.1. Thank you, -- Samuel Henrique rsync_3.2.3-4+deb11u1.debdiff Description: Binary data
Bug#999668: bullseye-pu: package jwm/2.3.7-5+deb11u1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] Fix segfault when using keyboard bindings to move a window for the first time (uninitialized variable). This issue is present on jwm 2.3.7, so it affects both stable and oldstable (It also affects testing but 2.4.0 is soon gonna migrate from unstable). [ Impact ] JWM will crash and exit if the user tries to move a window using the keyboard bindings for the first time (it won't if the window gets moved by the mouse first). [ Tests ] Manually reproduced the issue and confirmed that the fix addresses it. [ Risks ] I don't think there's a risk of a regression since the fix is a oneliner, initializing the variable. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Backport of an upstream patch that initializes the currentClient variable. [ Other info ] https://bugs.debian.org/977878 https://github.com/joewing/jwm/issues/410 https://github.com/rdnvndr/jwm/commit/d0e28abd8eb8748470f07595be6da5cec05b4939 As per the latest instructions from the release team, I have gone ahead and uploaded the fix already. -- Samuel Henrique jwm_2.3.7-5+deb11u1.debdiff Description: Binary data
Bug#1050974: binNMU: Rebuild against curl without NSS support
Hello Sebastian anb Paul, > So let's not just rebuild those. Samuel, please file bugs against those > packages so that the maintainers fix the build dependencies. I have filled bugs already, here's the current situation: eg25-manager: https://bugs.debian.org/1043547 Has been fixed in git already, so the next upload will have the correct B-D. llvm-toolchain-14 and llvm-toolchain-15: https://bugs.debian.org/1043550 https://bugs.debian.org/1043551 I have not explicitly asked for the B-D change for llvm, and I think doing it so will be a waste of time and effort, let me explain. Both llvm-toolchain-14 and llvm-toolchain-15 will be removed from the archive soon, see their ROM bugs: https://bugs.debian.org/1050069 https://bugs.debian.org/1050070 On top of that, those two packages have already been rebuilt for riscv64 (no binNMUs required there), whereas if we force another upload only to solve this, we will trigger a build for every arch and needlessly consume at the very least 77 hours of the riscv builders' time (while we are still rebuilding the archive for riscv, delaying it all). https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-14=riscv64 https://buildd.debian.org/status/logs.php?pkg=llvm-toolchain-15=riscv64 Do you think that's a sensible compromise? I'm asking to proceed with binNMUs because eg25-manager has been fixed in git already and the llvm packages are about to be removed (although I want curl to migrate before that), also rebuilding them on riscv takes a lot of effort at a not-so-great time (no binNMUs required for riscv). Note: llvm-toolchain-16, which is going to be the new default, has already fixed the B-D and the package has been uploaded, so that's why there's no action for that one. Thank you, -- Samuel Henrique
Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13
Package: release.debian.org Control: affects -1 + src:llvm-toolchain-14 X-Debbugs-Cc: llvm-toolchain...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1050974: nmu: llvm-toolchain-14_1:14.0.6-13
Right, so gmail added breaklines, correct command is: nmu llvm-toolchain-14_1:14.0.6-13 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x hurd-i386 sparc64 . unstable . -m "Rebuild against curl without NSS support" Cheers, -- Samuel Henrique
Bug#1050976: nmu: llvm-toolchain-15_1:15.0.7-8
Package: release.debian.org Control: affects -1 + src:llvm-toolchain-15 X-Debbugs-Cc: llvm-toolchain...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu llvm-toolchain-15_1:15.0.7-8 . all amd64 arm64 armel armhf i386 mips64el ppc64el s390x . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1050977: nmu: eg25-manager_0.4.6-1
Package: release.debian.org Control: affects -1 + src:eg25-manager X-Debbugs-Cc: eg25-mana...@packages.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: samuel...@debian.org Severity: normal nmu eg25-manager_0.4.6-1 . ANY . unstable . -m "Rebuild against curl without NSS support" -- Samuel Henrique
Bug#1050974: binNMU: Rebuild against curl without NSS support
Control: tags -1 - moreinfo Hello Sebastian, I'm sending this same response to all 3 bugs related to this. > Why does that require rebuilds? These packages have a build dependency on the virtual package "libcurl4-dev", which is satisfiable by any variant of the curl binaries (openssl, gnutls, nss). Our current builds ended up linking against the nss variant, so now that we've dropped that, a rebuild is needed for the packages to pick either openssl or gnutls. Related bugs: Main one where I'm tracking all changes: libcurl4-nss-dev: NSS support will be dropped in August 2023 https://bugs.debian.org/1038907 Bugs against the packages I'm requesting the binNMUs: llvm-toolchain-14: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043550 llvm-toolchain-15: links against libcurl3-nss which will be dropped in August 2023 https://bugs.debian.org/1043551 eg25-manager: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023 https://bugs.debian.org/1043547 Thank you, -- Samuel Henrique
Bug#1053998: bookworm-pu: package curl/7.88.1-10+deb12u5
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bookworm X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] This change provides DEB_VERSION on "--version" output. It's common for curl users to provide the output of "curl --version" when reporting issues, and there have been cases where having the version of the package in that output would have saved time (e.g.: if we don't know which distro the person is using and/or whether the package is up-to-date). Recently, on a Twitter thread, someone was assuming that a server was not patched for "CVE-2023-38545" because they only saw the upstream version. With this change, the "Release-Date" line of the output will change from e.g.: Release-Date: 2020-12-09 to: Release-Date: 2020-12-09, security patched: 7.88.1-10+deb12u4 [ Impact ] // Explained in the "Reason" section. [ Tests ] Curl has an extensive test suite and no failures were detected. [ Risks ] The only affected code is a single "printf" statement, which is changed to include the version: https://github.com/curl/curl/blob/curl-7_88_1/src/tool_help.c#L171-L176 There's a risk that scripts parsing the "Release-Date:" line from "--version" might fail to parse the date if the regex is badly written. I think it's very unlikely that there are scripts parsing that line of the output. Assuming there is one, and that it's using a bad regex, the risk is that it will match more than just the release date. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] d/rules is now importing "/usr/share/dpkg/pkg-info.mk" and setting "CURL_PATCHSTAMP" to the value of "DEB_VERSION". Effectively, this only changes the output of "curl --version" (on the "Release-Date" line). [ Other info ] I'm opening -pu bugs against bullseye, bookworm, and I'll check with the LTS team if they accept this change for buster. -- Samuel Henrique curl_7.88.1-10+deb12u5.debdiff Description: Binary data
Bug#1053997: bullseye-pu: package curl/7.74.0-1.3+deb11u11
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] This change provides DEB_VERSION on "--version" output. It's common for curl users to provide the output of "curl --version" when reporting issues, and there have been cases where having the version of the package in that output would have saved time (e.g.: if we don't know which distro the person is using and/or whether the package is up-to-date). Recently, on a Twitter thread, someone was assuming that a server was not patched for "CVE-2023-38545" because they only saw the upstream version. With this change, the "Release-Date" line of the output will change from e.g.: Release-Date: 2020-12-09 to: Release-Date: 2020-12-09, security patched: 7.88.1-10+deb12u4 [ Impact ] // Explained in the "Reason" section. [ Tests ] Curl has an extensive test suite and no failures were detected. [ Risks ] The only affected code is a single "printf" statement, which is changed to include the version: https://github.com/curl/curl/blob/curl-7_74_0/src/tool_help.c#L949-L954 There's a risk that scripts parsing the "Release-Date:" line from "--version" might fail to parse the date if the regex is badly written. I think it's very unlikely that there are scripts parsing that line of the output. Assuming there is one, and that it's using a bad regex, the risk is that it will match more than just the release date. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] d/rules is now importing "/usr/share/dpkg/pkg-info.mk" and setting "CURL_PATCHSTAMP" to the value of "DEB_VERSION". Effectively, this only changes the output of "curl --version" (on the "Release-Date" line). [ Other info ] I'm opening -pu bugs against bullseye, bookworm, and I'll check with the LTS team if they accept this change for buster. -- Samuel Henrique curl_7.74.0-1.3+deb11u11.debdiff Description: Binary data
Bug#1053781: unblock: curl/8.3.0-3
Package: release.debian.org
Control: affects -1 + src:curl
X-Debbugs-Cc: c...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: sergi...@debian.org, charlesmel...@riseup.net,
samuel...@debian.org
Severity: important
Please unblock package curl
[ Reason ]
The new package on unstable is fixing two just released CVEs, one low and one
high severity.
The high severity CVE can void the privacy of proxy users, by allowing remote
servers to trigger a local DNS resolution on the user's side.
These 2 CVEs have been fixed on bullseye-security, bullseye-backports,
bookworm-security, bookworm-backports and unstable.
I would like the fix to migrate to testing before running all CI tests and
waiting for the bake period.
[ Impact ]
The fix of the privacy-breaching CVE takes longer to reach testing, and
possibly longer to reach our derivatives as well.
CVE details:
CVE-2023-38545 (High sev)
https://curl.se/mail/lib-2023-10/0018.html
CVE-2023-38546 (Low sev)
https://curl.se/mail/lib-2023-10/0019.html
[ Tests ]
Curl's own testsuite ran and had no errors (we run that on dh_auto_test).
[ Risks ]
There were no considerable changes required to backport the patches, the only
change was a makefile adjustment due to the context having been changed. This
was for the new test and I've confirmed it is running.
The difference between the package on testing (revision -2) and unstable
(revision -3) is minimal too (only the two new patches).
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I purposedly backported the fix instead of packaging 8.4.0 to allow for a
faster migration to testing. Once it migrates, I'll push the pacckaging for
8.4.0.
The security team is about to release the fixes for bookworm-sec and
bullseye-sec. I have pushed the unstable, bookworm-bpo and bullseye-bpo just
now.
unblock curl/8.3.0-3
diff -Nru curl-8.3.0/debian/changelog curl-8.3.0/debian/changelog
--- curl-8.3.0/debian/changelog 2023-10-01 15:01:42.0 +0100
+++ curl-8.3.0/debian/changelog 2023-10-05 22:26:40.0 +0100
@@ -1,3 +1,9 @@
+curl (8.3.0-3) unstable; urgency=high
+
+ * Add patches to fix CVE-2023-38545 and CVE-2023-38546
+
+ -- Samuel Henrique Thu, 05 Oct 2023 22:26:40 +0100
+
curl (8.3.0-2) unstable; urgency=medium
* d/rules: Add test 3102 to TESTS_FAILS_ON_IPV6_ONLY_MACHINES
diff -Nru curl-8.3.0/debian/patches/CVE-2023-38545.patch
curl-8.3.0/debian/patches/CVE-2023-38545.patch
--- curl-8.3.0/debian/patches/CVE-2023-38545.patch 1970-01-01
01:00:00.0 +0100
+++ curl-8.3.0/debian/patches/CVE-2023-38545.patch 2023-10-05
22:26:40.0 +0100
@@ -0,0 +1,130 @@
+From a6c541e709096a09eb3df6a8fbbe058239d63a55 Mon Sep 17 00:00:00 2001
+From: Jay Satiro
+Date: Sat, 30 Sep 2023 03:40:02 -0400
+Subject: [PATCH] socks: return error if hostname too long for remote resolve
+
+Prior to this change the state machine attempted to change the remote
+resolve to a local resolve if the hostname was too long. Unfortunately
+that did not always work as intended, leading to a security issue. And
+when it did it's a privacy violation for users of socks5h that may
+expect their DNS requests will not leak.
+
+Bug: https://curl.se/docs/CVE-2023-38545.html
+
+Backported by: Samuel Henrique
+
+---
+ lib/socks.c | 13 +
+ tests/data/Makefile.inc | 2 +-
+ tests/data/test728 | 64 +
+ 3 files changed, 73 insertions(+), 6 deletions(-)
+ create mode 100644 tests/data/test728
+
+--- a/lib/socks.c
b/lib/socks.c
+@@ -585,11 +585,14 @@ static CURLproxycode do_SOCKS5(struct Cu
+ infof(data, "SOCKS5: connecting to HTTP proxy %s port %d",
+ sx->hostname, sx->remote_port);
+
+-/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
++/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet.
++ If remote resolve is enabled and the host is too long then error.
++ The user's resolve setting is not overridden because that could be a
++ privacy violation and unexpected. */
+ if(!socks5_resolve_local && hostname_len > 255) {
+- infof(data, "SOCKS5: server resolving disabled for hostnames of "
+-"length > 255 [actual len=%zu]", hostname_len);
+- socks5_resolve_local = TRUE;
++ failf(data, "SOCKS5: the destination hostname is too long to be "
++"resolved remotely by the proxy.");
++ return CURLPX_LONG_HOSTNAME;
+ }
+
+ if(auth & ~(CURLAUTH_BASIC | CURLAUTH_GSSAPI))
+@@ -903,7 +906,7 @@ CONNECT_RESOLVE_REMOTE:
+ }
+ else {
+ socksreq[len++] = 3;
+-socksreq[len++] = (char) hostname_len; /* one byte address length */
++socksreq[len++] = (unsigned char
Bug#1033273: unblock: curl/7.88.1-6
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl We have two changes on unstable: 1) Curl's test suite now skips flaky tests and it's critical to the result of the build: This means we get a FTBFS if tests fails, considering curl has a very extensive test-suite (around 1600 tests) and that this will increase the reliability of our backporting of patches throughout stable, oldstable and oldoldstable (hello lts/elts), this is very important. 2) Add support to PEM certificates for libcurl3-nss: When working on having the improved test coverage, we noticed the possibility to fix this long-standing bug. Users of libcurl3-nss are now able to load PEM certificates (like from ca-certificates), which makes it easier to run a safer libcurl with nss. [ Reason ] Major improvements to tests and fix of a long-standing bug related to usage of NSS and PEM certificates. [ Impact ] Maintenance of curl will be much more reliable from now on as we have better test coverage with results which can't be ignored. [ Tests ] I've run at least 8 builds of the curl package in our buildd infrastructure and didn't spot any flaky tests left. Regarding the NSS + PEM change, curl's extensive unit tests passed. [ Risks ] More work and less reliability maintaining curl on trixie (for backporting patches, for example). [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] I would like 7.88.1-6 to migrate as soon as possible (it has been more than 10 days already) because I want to push 6 CVE fixes after this upload. I will also request for the CVE fixes to be unblocked but I would like this version to migrate first so it happens sooner (trying to avoid baking this for an extra 20 days). unblock curl/7.88.1-6 Thank you, -- Samuel Henrique curl_7.88.1-6.debdiff Description: Binary data
Bug#1033469: unblock: curl/7.88.1-7
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl I would like to push the fix for the recent 6 CVEs disclosed: - CVE-2023-27533: TELNET option IAC injection - CVE-2023-27534: SFTP path ~ resolving discrepancy - CVE-2023-27535: FTP too eager connection reuse - CVE-2023-27536: GSS delegation too eager connection re-use - CVE-2023-27537: HSTS double-free - CVE-2023-27538: SSH connection too eager reuse still I have also prepared the fixes for stable and oldstable and will be requesting a p-u upload for them shortly (already pushed the commits to the repo). I would also appreciate it if the wait time for the migration could be cut short due to the nature of the changes (low risk and the sooner they get to testing the better). [ Reason ] CVE fixes, the security team said no DSAs will be assigned to them. [ Impact ] The highest severity of the CVEs is moderate as per upstream, the security team considered all of them low (thus no DSA). [ Tests ] Curl's test suite passed (the build succeeded on all archs). [ Risks ] Only minimal changes were required in order to backport CVE-2023-27533. There has been no bugfixes related to these CVE fixes in 8.0.1. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Other small changes in the debdiff are: Bump Standards-Version to 4.6.2 d/p/06_always-disable-valgrind.patch: Remove unused patch d/patches: Refresh all patches None of these three changes modifies the resulting binaries. I am planning to push 7.88.1-8 after 7.88.1-7 migrates and I will be requesting an unblock for that revision as well, I figured it's better to not bundle the changes together to make the review easier and to let the CVE fixes get to testing sooner. The changes for -8 will be: 1) Inclusion of autopkgtests. 2) Inclusion of new build profiles to limit the builds to certain TLS backends (to be used by manual tests or autopkgtests only). 3) And possibly a fix for the multi-arch issue #913995 (the lintian error that the package has). I would also like to ask the release team to consider unblocking curl' s latest release 8.0.1 due to the delta consisting of mostly bugfixes (biggest change is removal of support for systems that don't have 64 bit data types). Being able to ship 8.0.1 will make maintenance easier on the long term (stable, oldstable...). But I want to first get these CVE fixes and the autopkgtests (coming in rev 8) in testing before asking for 8.0.1's unblock. PS.: I've made a typo in the changelog entry where I mention "5 CVEs" rather than 6, but it's fine since all of the 6 CVEs are listed anyway. unblock curl/7.88.1-7 -- Samuel Henrique curl_7.88.1-7.debdiff Description: Binary data
Bug#1033721: unblock: curl/7.88.1-8
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: sergi...@debian.org, samuel...@debian.org Severity: normal Please unblock package curl [ Reason ] Changes that affect the resulting binaries: * d/rules: Remove -D_DEB_HOST_ARCH from curl-config's CFLAGS We have accidentally introduced a small regression at 7.88.1-3 which would make the dev packages not multi-arch compatible (even though we set Multi-Arch: same). This change fixes that by removing the unneeded build flag that gets set in the curl-config file. Changes that don't affect the resulting binaries: * d/gbp.conf: Push gbp conf with sane defaults * d/salsa-ci.yml: Disable dh_auto_test with DEB_BUILD_OPTIONS * d/rules: Add new build profiles to limit builds to a single TLS backend * d/tests: Add new autopkgtests that runs curl's test suite The most important one from this list is the inclusion of autopkgtests, which run all of curl's test suite for each TLS backend that we support (openssl, gnutls and nss). [ Impact ] One multi-arch bugfix and extra reliability/stability of the package with the inclusion of autopkgtests and salsa-ci (to make stable updates easier). [ Tests ] All build tests passed. [ Risks ] No risks that I can think of. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] I have also attached a diffoscope diff from the amd64 binary to show the multi-arch fix's delta. I'm not in a rush to get the package in testing, but there's also no harm in removing the bake time for the migration, so I would appreciate it if that could be done (only if that's not too much work for the release team). unblock curl/7.88.1-8 -- Samuel Henrique curl_7.88.1-8.debdiff Description: Binary data --- libcurl4-openssl-dev_7.88.1-7_amd64.deb +++ libcurl4-openssl-dev_7.88.1-8_amd64.deb ├── file list │ @@ -1,3 +1,3 @@ │ --rw-r--r-- 0004 2023-03-21 22:39:05.00 debian-binary │ --rw-r--r-- 000 1672 2023-03-21 22:39:05.00 control.tar.xz │ --rw-r--r-- 000 484468 2023-03-21 22:39:05.00 data.tar.xz │ +-rw-r--r-- 0004 2023-03-26 10:36:24.00 debian-binary │ +-rw-r--r-- 000 1676 2023-03-26 10:36:24.00 control.tar.xz │ +-rw-r--r-- 000 484612 2023-03-26 10:36:24.00 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── file list │ │ │ @@ -1,3 +1,3 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./ │ │ │ --rw-r--r-- 0 root (0) root (0) 1467 2023-03-21 22:39:05.00 ./control │ │ │ --rw-r--r-- 0 root (0) root (0) 1524 2023-03-21 22:39:05.00 ./md5sums │ │ │ +drwxr-xr-x 0 root (0) root (0)0 2023-03-26 10:36:24.00 ./ │ │ │ +-rw-r--r-- 0 root (0) root (0) 1467 2023-03-26 10:36:24.00 ./control │ │ │ +-rw-r--r-- 0 root (0) root (0) 1524 2023-03-26 10:36:24.00 ./md5sums │ │ ├── ./control │ │ │ @@ -1,14 +1,14 @@ │ │ │ Package: libcurl4-openssl-dev │ │ │ Source: curl │ │ │ -Version: 7.88.1-7 │ │ │ +Version: 7.88.1-8 │ │ │ Architecture: amd64 │ │ │ Maintainer: Alessandro Ghedini │ │ │ Installed-Size: 1763 │ │ │ -Depends: libcurl4 (= 7.88.1-7) │ │ │ +Depends: libcurl4 (= 7.88.1-8) │ │ │ Suggests: libcurl4-doc, libidn-dev, libkrb5-dev, libldap2-dev, librtmp-dev, libssh2-1-dev, libssl-dev, pkg-config, zlib1g-dev │ │ │ Conflicts: libcurl4-gnutls-dev, libcurl4-nss-dev, libssl1.0-dev │ │ │ Provides: libcurl-dev, libcurl-ssl-dev, libcurl3-dev, libcurl3-openssl-dev, libcurl4-dev │ │ │ Section: libdevel │ │ │ Priority: optional │ │ │ Multi-Arch: same │ │ │ Homepage: https://curl.se/ │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ ├── data.tar.xz │ ├── data.tar │ │ ├── file list │ │ │ @@ -1,36 +1,36 @@ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/bin/ │ │ │ --rwxr-xr-x 0 root (0) root (0) 6465 2023-03-21 22:39:05.00 ./usr/bin/curl-config │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/x86_64-linux-gnu/ │ │ │ -drwxr-xr-x 0 root (0) root (0)0 2023-03-21 22:39:05.00 ./usr/include/x86_64-linux-gnu/curl/ │ │ │ --rw-r--r-- 0 root (0) root (0) 127742 2023-03-21 22:39:05.00 ./usr/include/x86_64
Bug#1036809: unblock: reaver/1.6.6-0.1
Hey everyone, Considering this will be the only fix we get, leaving the release team to decide between not shipping reaver at all or shipping "1.6.6-0.1", I went ahead and sponsored the upload from Leandro. The debdiff is attached. Thank you, -- Samuel Henrique reaver_1.6.6-0.1.debdiff Description: Binary data
Bug#1036801: unblock: curl/7.88.1-10
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: unblock Severity: normal Please unblock package curl [ Reason ] 4 CVE fixes: * Add new patches to fix CVEs (closes: #1036239): - CVE-2023-28319: UAF in SSH sha256 fingerprint check - CVE-2023-28320: siglongjmp race condition - CVE-2023-28321: IDN wildcard match - CVE-2023-28322: more POST-after-PUT confusion * d/libcurl*.symbols: Drop curl_jmpenv, not built anymore due to CVE-2023-28320 [ Impact ] The highest CVE severity from upstream is "Moderate". [ Tests ] Curl has an extensive test suite that's run at build time and on autopkgtest, no regressions were detected. [ Risks ] The patches didn't require any changes which would be worrying. Regarding the "curl_jmpenv", there's no package on Debian using that. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] Please also shorten the bake time in unstable, is possible (and needed). unblock curl/7.88.1-10 -- Samuel Henrique curl_7.88.1-10.debdiff Description: Binary data
Bug#1036300: Fwd: bullseye-pu: package curl/7.74.0-1.3+deb11u8
Package: release.debian.org Control: affects -1 + src:curl X-Debbugs-Cc: c...@packages.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: bullseye X-Debbugs-Cc: samuel...@debian.org Severity: normal [ Reason ] * Backport upstream patches to fix 5 CVEs: - CVE-2023-27533: TELNET option IAC injection - CVE-2023-27534: SFTP path ~ resolving discrepancy - CVE-2023-27535: FTP too eager connection reuse - CVE-2023-27536: GSS delegation too eager connection re-use - CVE-2023-27538: SSH connection too eager reuse still * d/p/add_Curl_timestrcmp.patch: New patch to backport Curl_timestrcmp(), required for CVE-2023-27535. [ Impact ] None of the vulnerabilities are critical, but they have already been fixed in buster and we should do the same for bullseye. [ Tests ] curl's testsuite didn't spot any regressions. The same CVEs have also been fixed in buster already. [ Risks ] Regressions on TELNET, SFTP, FTP, GSS and SSH functionalities of curl. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Nothing besides the CVE fixes. The patches were changed to apply cleanly on bullseye, all the changes can be seen here: https://salsa.debian.org/debian/curl/-/commit/4adf0d7c4d47610336294d39f84a8360522a5936 https://salsa.debian.org/debian/curl/-/commit/b3dedba95658cea02405af32f0652f83d87f6eac https://salsa.debian.org/debian/curl/-/commit/6909425ffa87e4c35730ecc2801ef40492239048 https://salsa.debian.org/debian/curl/-/commit/54e6a929643fe14160049ed8d1bda72dd34db9f7 https://salsa.debian.org/debian/curl/-/commit/19c382231a004b45b3096f72fb722f6df5d31902 [ Other info ] I will be working on the latest CVEs that have been published for curl but I'll push those fixes in a different upload. -- Samuel Henrique curl_7.74.0-1.3+deb11u8.debdiff Description: Binary data
Bug#1036801: unblock: curl/7.88.1-10
Hello Salvatore, > After a short discussion with Paul, wouldn't that imply though that > there is an soname bump needed? Do you know has upstream considered > this and if/or why not? Is there enough assurance nobody (even outside > Debian world) is using that symbol? Those are all good questions, I should have done a better job at explaining this, so let me try doing it now. sergiodj@ did a lot of work investigating this as well, so most of the things I'll be saying here are his findings (although if I say anything wrong here, blame it on me). The "curl_jmpenv" variable declaration was guarded by a "#ifdef HAVE_SIGSETJMP", but the variable would only be used on "#ifdef USE_ALARM_TIMEOUT". For Debian, "HAVE_SIGSETJMP" is true but "USE_ALARM_TIMEOUT" is false, this is because we use the threaded resolver. This means that "curl_jmpenv" was dead code, and double checking for mentions of "curl_jmpenv" on codesearch.d.n only returns packages which bundles curl, nothing using it. Considering the variable was exposed, but not used anywhere (in our builds with threaded resolver), I don't think there was any possible way dependencies could be making use of it in any meaningful way (this is talking about things outside of our official repositories now). It doesn't make sense for upstream to bump SONAME because the variable can still be exposed depending on the build config, it's just that it wasn't supposed to be exposed for threaded resolvers first of all. The CVE that is being fixed by that change should not affect our binaries since we build with the threaded resolver, but I ended up making a decision to still apply the patch to safeguard even the sources. > These are just a couple of question trying to understand what > potential question from release team members my come for your unblock > request. Thank you for reviewing this. > p.s.: note it looks autopkgtest view for curl was still blocking it > because cwltool has a flaky test (on armel). Yeah, curl suffers quite a bit from these since tons of reverse-deps use it to fetch resources over the network and that's always flaky (not sure if it's the case with cwitool specifically, but I'm used to this sort of thing by now). Cheers, -- Samuel Henrique
Debian 8.3 Jessie KEYEXPIRED 11645052400
Hello, On Sat, May 13, 2023, 11:31 Pierre-Elliott Bécue wrote: > > The only way to avoid that would be to first add stretch to your > sources.list, update, install debian-archive-keyring, and then add > buster to your sources.list. > By the way, this is the recommended approach, please don't try to upgrade from 8 directly to 10, this is not officially supported. Do an upgrade to 9 first, then another one to 10, and also consider upgrading to 11, if possible, since the next stable release (12) will happen in a few months. Make sure you're following the official instructions to perform release upgrades as well. In order to use the repositories for old releases (to upgrade to 9), you will need to use Freexian's repository [0] (which provides LTS and ELTS support), alternatively you can also point to the "archives" repositories [1]. When upgrading to 10 or 11, you should be good to use the regular repositories, this happens because releases 8 and 9 are not officially supported anymore (support being provided by Freexian instead). Trying to generalize the support provided by Debian releases, it's mostly like this: 3 years of official support +2 years of LTS support provided by Freexian (you need to use their repositories) +5 years of ELTS support, also provided by Freexian (and so you need to use their repositories). In total that's 10 years. Note that LTS and ELTS support does not cover all packages (just as you would get with other enterprise distros). Also note that Freexian's support, although not officially affiliated to Debian (as far as I know), it's done by Debian Developers. Their work is funded through customers/sponsors of Freexian and provided for free for everyone to use (so consider sponsoring it if you use it in a company, I think they can also provide direct support to you). Check their website for more info [3]. Disclaimer: I am not affiliated with Freexian. [0] https://www.freexian.com/lts/extended/docs/how-to-use-extended-lts/ [1] https://www.debian.org/distrib/archive [2] https://www.freexian.com
Question about non-maintainer proposed-updates
Hello team,
Lately I've been helping new contributors on learning how to contribute by
preparing CVE fixes for our packages.
Fortunately I was able to find CVEs from packages I own myself, which made the
process a bit easier, but I would like to be able to pick other packages CVEs
to work on ("no-dsa" ones).
So the question is, does the release team consider it ok to push
proposed-updates without having to go through the package maintainer (given we
follow the regular process for p-u uploads)?
I would love it if that could be the case, as having to get the maintainer's
approval is too much overhead so that one might decide to spend their time
doing something else. I have an impression that this is allowed already but
wanted to confirm.
In case the release team says we have to reach out to the maintainer, would it
be possible to provide some rough guidelines? For example: "cc'ing the
maintainer on the release.d.o p-u bug report is all that's needed", or "open up
a bug against the package indicating your intention to do a p-u upload".
Would the answer be the same for any type of p-u upload? I assume a no-dsa CVE
fix and a regular bug fix would fall into the same bucket (that's why I've made
the email subject generic).
My end goal is to get new contributors interested in fixing CVEs and improve
the overall quality of our releases.
Cheers,
--
Samuel Henrique
