Re: [OE-core] [scarthgap][PATCH] dropbear: Disable DSS correctly

[Mike Crowe <mac@mcrowe.com>]

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 <mac@mcrowe.com>
> >
> > 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 <mac@mcrowe.com>
> > ---
> >  ...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 <matt@ucc.asn.au>
> > +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.

Thanks.

Mike.