[swugenerator] RFC signing function

[ing...@gmail.com]

In some productive systems it might be required to do the signing of the swu

file in an isolated and restricted environment (special server,

credentials, pipeline, etc.). In that case the swugenerator can only do the

unsigned generation of a swu-file and an additional step to extract, sign

and pack again would be needed.

Would it be an acceptable improvement to implement a "sign" feature in

addition to the "create" function?

It would take an swu-file (input, output) and signing options to sign the swu-file.

Consider this imaginary example:

  # Build pipeline run. Already implemented in swugenerator.

  swugenerator -s sw-description.in -o foo-unsigned.swu -c config create

  # Signing pipeline run. Not yet implemented.

  swugenerator -i foo-unsigned.swu -o foo-signed.swu -k

     PKCS11,mypin,libnethsm_pkcs11.so,0,12345 sign

Thanx for the feedback in advance, if ok, I can start to work on a patch,

regards, INgo

[Stefano Babic]

Hi Ingo,

On 10/2/25 08:48, ing...@gmail.com wrote:
> In some productive systems it might be required to do the signing of the swu
> file in an isolated and restricted environment (special server,
> credentials, pipeline, etc.). In that case the swugenerator can only do the
> unsigned generation of a swu-file and an additional step to extract, sign
> and pack again would be needed.

swugenerator is in fact already used to solve this. It has built-in
signing features using openSSL, but it can run a custom script that user
can adapt to own needs.

--sign CUSTO,<script>,<parms1>,...<parmsn>

> Would it be an acceptable improvement to implement a "sign" feature in
> addition to the "create" function?

A sign or "re-sign" feature makes sense to avoid the manual unpacking of
an already created SWU. This is currently done by executing first cpio
and the swugenerator. It will work until cpio format is supported and I
have not to change.

> It would take an swu-file (input, output) and signing options to sign
> the swu-file.
>
> Consider this imaginary example:
>   # Build pipeline run. Already implemented in swugenerator.
>   swugenerator -s sw-description.in -o foo-unsigned.swu -c config create
>   # Signing pipeline run. Not yet implemented.
>   swugenerator -i foo-unsigned.swu -o foo-signed.swu -k
>      PKCS11,mypin,libnethsm_pkcs11.so,0,12345 sign

So the feature will add an unpacking first, and then it runs as create
like now, right ?

>
> Thanx for the feedback in advance, if ok, I can start to work on a patch,
> regards, INgo

Best regards,
Stefano Babic

[ing...@gmail.com]

Hi Stefano, thanx for the quick reply.

On Thu, Oct 2, 2025 at 9:27 AM Stefano Babic <stefan...@swupdate.org> wrote:
>
> swugenerator is in fact already used to solve this. It has built-in
> signing features using openSSL, but it can run a custom script that user
> can adapt to own needs.
>
>         --sign CUSTO,<script>,<parms1>,...<parmsn>

I am fully aware of the custom sign and I proved that to be working calling a bash script...but that's seems like a hack, delegating the working within swugenerator to a completely different process/machine.

>
> > Would it be an acceptable improvement to implement a "sign" feature in
> > addition to the "create" function?
>

> So the feature will add an unpacking first, and then it runs as create
> like now, right ?

Yes, that's the intention, making use of swugenerator because it has all features for it
and supports future changes.

Regards, INgo

[Stefano Babic]

Hi Ingo,

On 10/2/25 12:27, ing...@gmail.com wrote:
> Hi Stefano, thanx for the quick reply.
>
> On Thu, Oct 2, 2025 at 9:27 AM Stefano Babic
> <stefan...@swupdate.org> wrote:
>>
>> swugenerator is in fact already used to solve this. It has built-in
>> signing features using openSSL, but it can run a custom script that user
>> can adapt to own needs.
>>
>>         --sign CUSTO,<script>,<parms1>,...<parmsn>
> I am fully aware of the custom sign and I proved that to be working
> calling a bash script...but that's seems like a hack, delegating the
> working within swugenerator to a completely different process/machine.

There are a lot of use cases where companies have developed thier own
way for signing. A quite common way is that they have a server (signing
server), and with the custom script they send the request with
sw-description and they receive the signature. However, these are
proprietary solutions, and cannot be integrated.

>>
>> > Would it be an acceptable improvement to implement a "sign" feature in
>> > addition to the "create" function?
>>
>> So the feature will add an unpacking first, and then it runs as create
>> like now, right ?
>
> Yes, that's the intention, making use of swugenerator because it has all
> features for it
> and supports future changes.

Ok, fine.

Best regards,
Stefano

> >   swugenerator -s sw-description.in <http://sw-description.in> -o

> foo-unsigned.swu -c config create
> >   # Signing pipeline run. Not yet implemented.
> >   swugenerator -i foo-unsigned.swu -o foo-signed.swu -k
> >      PKCS11,mypin,libnethsm_pkcs11.so,0,12345 sign
>
> So the feature will add an unpacking first, and then it runs as create
> like now, right ?
>
> >
> > Thanx for the feedback in advance, if ok, I can start to work on
> a patch,
> > regards, INgo
>
> Best regards,
> Stefano Babic
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/040ff741-6e91-410f-97d9-8a18ad24171en%40googlegroups.com
> <https://groups.google.com/d/msgid/
> swupdate/040ff741-6e91-410f-97d9-8a18ad24171en%40googlegroups.com?
> utm_medium=email&utm_source=footer>.