[PATCH] CRYPTO: Resolve default configuration regression on SIGALG_RAWRSA

[Adrian DC]

In commit cc218ee52107a34712497eb33d57047647e29d27,
sources were moved from 'Kconfig' to 'crypto/Kconfig'.

However, the move has a silent sources change that is masked by the move:
Menu 'Signature verification algorithm' had 'SIGALG_RAWRSA' as default 'y',
but it became 'n' by default after this move commit.

If the project is built without explicitly setting 'SIGALG_RAWRSA',
SWUpdate shall run without a signature verification algorithm and fail
---

Signed-off-by: Adrian DC <radi...@gmail.com>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 48eeb01c..4f109fd0 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -49,7 +49,7 @@ menu "Signature verification algorithm"

config SIGALG_RAWRSA
bool "RSA PKCS#1.5"
- default n
+ default y
depends on SSL_IMPL_OPENSSL || SSL_IMPL_WOLFSSL || SSL_IMPL_MBEDTLS

config SIGALG_RSAPSS
--
2.43.0

[Stefano Babic]

Hi Adrian,

On 1/28/26 15:38, Adrian DC wrote:
> In commit cc218ee52107a34712497eb33d57047647e29d27,
> sources were moved from 'Kconfig' to 'crypto/Kconfig'.
>
> However, the move has a silent sources change that is masked by the move:
> Menu 'Signature verification algorithm' had 'SIGALG_RAWRSA' as default 'y',
> but it became 'n' by default after this move commit.
>
> If the project is built without explicitly setting 'SIGALG_RAWRSA',
> SWUpdate shall run without a signature verification algorithm and fail
> ---
>

Well, I am not sure about this. It fails yes, but the change wasn't just
to move it, but to allow to have multiple providers and verification
algorithms without rebuilding the code. So at the same time, you can
have SIGALG_RAWRSA, SIGALG_CMS, ..

So why should be RSA under the hood been activated ? Maybe it is better
to see the error, so that the integrator checks this and choose the
algorithm. If we activate this as default, it will be fine for all using
simple RSA keys, but more difficult to check for users using another alg.

Best regards,
Stefano Babic

[Adrian DC]

Hi Stefano,

Thanks for your feedback.

I'm aligned with the split of sources, however the commit was to move sources yet introduced a breaking change silently,
it can't be reviewed since the file was not renamed but the lines moved, hence Git can't diff it.

Upon SWUpdate major release upgrade (Yocto kirkstone with 2023.12.1 through 25.05, to scarthgap with 2025.12),
we had to investigate the missing algorithm crash and test commits with dichotomy to identify the origin.

Then it does become obvious we have to configure and choose of course.

Moreover, I think this patch aligns with the logic of this Kconfig where 'SSL_IMPL_OPENSSL' is default 'y' and can be overridden at one's will.

I let it to your vision if default should be fixed or if a note about the "regression" upon upgrade is preferred.
When known each of us provide the needed configurations and it works just fine.

Best regards,

Adrian DC

[Stefano Babic]

Hi Adrian,

On 1/28/26 18:38, Adrian DC wrote:
> Hi Stefano,
>
> Thanks for your feedback.
>
> I'm aligned with the split of sources, however the commit was to move
> sources yet introduced a breaking change silently,
> it can't be reviewed since the file was not renamed but the lines moved,
> hence Git can't diff it.

Yes, it was a big change, not just renamed, but the whole crypto was
thought again.

>
> Upon SWUpdate major release upgrade (Yocto kirkstone with 2023.12.1
> through 25.05, to scarthgap with 2025.12),
> we had to investigate the missing algorithm crash and test commits with
> dichotomy to identify the origin.
>
> Then it does become obvious we have to configure and choose of course.
>
> Moreover, I think this patch aligns with the logic of this Kconfig where
> 'SSL_IMPL_OPENSSL' is default 'y' and can be overridden at one's will.

Ok - in any case, your patch does not break anything and it could be
merged without issues.

>
> I let it to your vision if default should be fixed or if a note about
> the "regression" upon upgrade is preferred.

I will merge this, but I agree that something more in documentation can
be added.

> When known each of us provide the needed configurations and it works
> just fine.
>

Fine, I apply this then.

Best regards,
Stefano Babic



> Best regards,
> *Adrian DC*