On Thu Jul 9, 2026 at 9:33 PM CEST, Alex Kiernan wrote: > On Thu, Jul 9, 2026 at 8:07 PM Mike Crowe via lists.openembedded.org > <[email protected]> wrote: >> >> Hi Yoann, >> >> On Tuesday 07 July 2026 at 10:54:38 +0200, Yoann Congal wrote: >> > On Mon Jun 29, 2026 at 6:50 PM CEST, Mike Crowe via lists.openembedded.org >> > wrote: >> > > From: Mike Crowe <[email protected]> >> > > >> > > Take upstream patch that stops sysoptions.h unconditionally turning >> > > DROPBEAR_DSS back on even when it has been disabled (which is the >> > > default). >> > > >> > > Signed-off-by: Mike Crowe <[email protected]> >> > > --- >> > > ...PBEAR_DSS-is-only-forced-for-fuzzing.patch | 29 +++++++++++++++++++ >> > > .../recipes-core/dropbear/dropbear_2022.83.bb | 1 + >> > > 2 files changed, 30 insertions(+) >> > > create mode 100644 >> > > meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch >> > > >> > > diff --git >> > > a/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch >> > > >> > > b/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch >> > > new file mode 100644 >> > > index 0000000000..b9705a2bbb >> > > --- /dev/null >> > > +++ >> > > b/meta/recipes-core/dropbear/dropbear/0001-Fix-so-DROPBEAR_DSS-is-only-forced-for-fuzzing.patch >> > > @@ -0,0 +1,29 @@ >> > > +From c7dfaebd5f6a4cde4198f4d2a7baabaa1f632274 Mon Sep 17 00:00:00 2001 >> > > +From: Matt Johnston <[email protected]> >> > > +Date: Tue, 6 Dec 2022 22:34:11 +0800 >> > > +Subject: [PATCH] Fix so DROPBEAR_DSS is only forced for fuzzing >> > > + >> > > +Regression from 787391ea3b5af2acf5e3c83372510f0c79477ad7, >> > > +was missing fuzzing conditional >> > > + >> > > +Upstream-Status: Backport >> > > [https://github.com/mkj/dropbear/commit/c043efb47c3173072fa636ca0da0d19875d4511f] >> > >> > This patch is missing your signed-off-by. >> >> Well, it's not my patch. :) >> >> I wasn't aware that I was expected to add one to the patch itself for a >> backport. >> >> https://docs.yoctoproject.org/scarthgap/contributor-guide/recipe-style-guide.html >> doesn't seem to say that a SoB should be added to the patch. It does say: >> >> | Of course, if another person later takes care of submitting this patch >> | upstream, the status should be changed to Submitted [where], and an >> | additional Signed-off-by: line should be added to the patch by the person >> | claiming responsibility for upstreaming. >> >> which sort of implies that a SoB should be added for original patches that >> are suitable for upstreaming but this patch is a backport which originated >> upstream (without a SoB) which isn't the same thing. >> >> Adding a SoB to an unmodified upstream backport patch feels like >> appropriation on my part, but I can do so if that's the policy. >> > > You're certifying that the patch you're submitting is appropriately > licensed; it says nothing about who authored it.
I agree with Alex: As the one requesting the backport, you are the one signing-off on this particular operation. The original author had nothing to do with that. I created a bug to request clarification in the doc on this point: 16356 – Clarify trailers usage (Signed-off-by, ...) in imported patches https://bugzilla.yoctoproject.org/show_bug.cgi?id=16356 Regards, -- Yoann Congal Smile ECS
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#240596): https://lists.openembedded.org/g/openembedded-core/message/240596 Mute This Topic: https://lists.openembedded.org/mt/120033783/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
