public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>
To: "isar-users@googlegroups.com" <isar-users@googlegroups.com>
Cc: "Schmidt, Adriaan" <adriaan.schmidt@siemens.com>,
	"Kiszka, Jan" <jan.kiszka@siemens.com>
Subject: local Bash variables leak into bitbake signatures
Date: Tue, 26 Nov 2024 16:15:57 +0000	[thread overview]
Message-ID: <d5140d714ca7d97bd0a8c1bdbd87df47a6eb94fb.camel@siemens.com> (raw)

Hi,

while debugging the ca-certificates problem, I noticed that our SState
siginfo files contain a lot of garbage. This happens, as all variables
in a shell function that are at least once accessed using ${foo} syntax
(bitbake syntax) are added to the signatures (without a value). This is
problematic for the following reasons:

1. The variable names (esp. very short ones) can easily collide with a
bitbake task name. Then the content of the task is copy-pasted to the
location the variable is accessed.

2. Signature size. Probably not too relevant yet, but when manually
inspecting the signatures that's really annoying.

Despite in "normal" shell code, in bitbake it is NOT a good habit to
access shell variables with the curly brace pattern. IOW, this is
discouraged. I don't know why they still have the following statement
in their docs:

> If the variable expansion syntax is used on a variable that does not
> exist, the string is kept as is.

In my opinion we should fix this and enforce it with a rule in the to-
be-written ISAR linter.

I know, there are some cases where this pattern cannot be avoided, but
these could be replaced by a python generator (like
${@bash_var('foo')).

Best regards,
Felix Moessbauer
Siemens AG

-- 
Siemens AG, Technology
Linux Expert Center


-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/d5140d714ca7d97bd0a8c1bdbd87df47a6eb94fb.camel%40siemens.com.

                 reply	other threads:[~2024-11-26 16:16 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5140d714ca7d97bd0a8c1bdbd87df47a6eb94fb.camel@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=adriaan.schmidt@siemens.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox