Skip to content

Use macro rather than shell expansion for string processing in spec file#8511

Merged
alexey-tikhonov merged 2 commits intoSSSD:masterfrom
nforro:packit
Mar 16, 2026
Merged

Use macro rather than shell expansion for string processing in spec file#8511
alexey-tikhonov merged 2 commits intoSSSD:masterfrom
nforro:packit

Conversation

@nforro
Copy link
Copy Markdown
Contributor

@nforro nforro commented Mar 11, 2026

We've hardened security in Packit Service and shell expansions in spec files are now rejected as they can be used to execute arbitrary code. There is no need to use shell expansion for string processing, there is an existing macro for this very purpose.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request addresses a security concern by replacing a shell expansion in the sssd.spec.in file with a built-in RPM macro. The change from %(echo "@PACKAGE_VERSION@" | sed 's/-/~/g') to %{gsub @PACKAGE_VERSION@ - ~} for version string processing is correct and effectively mitigates the risk of arbitrary code execution. This is a good improvement for security and maintainability. I have no further comments or suggestions.

Note: Security Review is unavailable for this PR.

@nforro
Copy link
Copy Markdown
Contributor Author

nforro commented Mar 11, 2026

Sorry, I thought getting rid of shell expansion in Version would suffice but unfortunately it's not enough. Let me see if there is a solution.

Comment thread contrib/sssd.spec.in Outdated
%package common
Summary: Common files for the SSSD
License: GPL-3.0-or-later
%if "%{?samba_package_version}" != ""
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please forgive my ignorance - where is this macro defined?

Copy link
Copy Markdown
Contributor

@thalman thalman Mar 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please ignore. I got it.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why it can be missing?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, is this because Packit Service doesn't allow

%(rpm -q samba-devel --queryformat %{version})

anymore?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of wrapping every 'Requires:', let's better define samba_package_version to something in this case.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to re-define the same samba_package_version without introduction of new minimal_samba_version?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO it should be possible to set it like this

%global samba_package_version %(rpm -q samba-devel --queryformat %{version})

%if "%{?samba_package_version}" != ""
%global samba_package_version 4.19
%endif

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I meant.

With a small note there is likely a mistype in:

%if "%{?samba_package_version}" != ""

-- we need to check when it's equal.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to re-define the same samba_package_version without introduction of new minimal_samba_version?

AFAICT it's not a good practice, as it could have unintended side-effects, but it this case I think it should be fine. I've updated the commit.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you.

Copy link
Copy Markdown
Contributor

@thalman thalman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update, ACK

nforro added 2 commits March 16, 2026 10:19
Signed-off-by: Nikola Forró <nforro@redhat.com>
Reviewed-by: Tomáš Halman <thalman@redhat.com>
Signed-off-by: Nikola Forró <nforro@redhat.com>
Reviewed-by: Tomáš Halman <thalman@redhat.com>
@sssd-bot
Copy link
Copy Markdown
Contributor

The pull request was accepted by @thalman with the following PR CI status:


🟢 CodeQL (success)
🟢 osh-diff-scan:fedora-rawhide-x86_64:upstream (success)
🟢 rpm-build:centos-stream-10-x86_64:upstream (success)
🟢 rpm-build:fedora-42-x86_64:upstream (success)
🟢 rpm-build:fedora-43-x86_64:upstream (success)
🟢 rpm-build:fedora-44-x86_64:upstream (success)
🟢 rpm-build:fedora-rawhide-x86_64:upstream (success)
🟢 Analyze (target) / cppcheck (success)
🟢 Build / freebsd (success)
🟢 Build / make-distcheck (success)
🟢 ci / intgcheck (centos-10) (success)
🟢 ci / intgcheck (fedora-42) (success)
🟢 ci / intgcheck (fedora-43) (success)
🟢 ci / intgcheck (fedora-44) (success)
🟢 ci / intgcheck (fedora-45) (success)
🟢 ci / prepare (success)
🟢 ci / system (centos-10) (success)
🟢 ci / system (fedora-42) (success)
🟢 ci / system (fedora-43) (success)
🟢 ci / system (fedora-44) (success)
🟡 ci / system (fedora-45) (in_progress)
➖ Coverity scan / coverity (skipped)
🟢 Static code analysis / codeql (success)
🟢 Static code analysis / pre-commit (success)
🟢 Static code analysis / python-system-tests (success)


There are unsuccessful or unfinished checks. Make sure that the failures are not related to this pull request before merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants