Zen

Source string Source string

511/10000 · 511

The string is read only.

English Actions
Verify the string specified in the License tag of the RPM metadata describes permissible software licenses as defined by the license database. Also checks to see if the License tag contains any unprofessional words as defined in the configuration file.
Check all binary RPMs in the build for any empty payloads. When comparing two builds, report new packages in the after build with empty payloads.
Check all binary RPMs in the before and after builds for any empty payloads. Packages that lost payload data from the before build to the after build are reported.
Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
Perform some checks on man pages in the RPM payload. First, check that each man page is compressed. Second, check that each man page contains valid content. Lastly, check that each man page is installed to the correct path.
Check that XML files included in the RPM payload are well-formed.
Perform several checks on ELF files. First, check that ELF objects do not contain an executable stack. Second, check that ELF objects do not contain text relocations. When comparing builds, check that the ELF objects in the after build did not lose a PT_GNU_RELRO segment. When comparing builds and there is a list of forbidden library functions, make sure nothing uses them.
Perform several checks on ELF files. First, check that ELF objects do not contain an executable stack. Second, check that ELF objects do not contain text relocations. When comparing builds, check that the ELF objects in the after build did not lose a PT_GNU_RELRO segment. When comparing builds, check that the ELF objects in the after build did not lose -D_FORTIFY_SOURCE. Lastly, if there is a list of forbidden library functions, make sure nothing uses them.
Perform syntax and file reference checks on *.desktop files. Syntax errors and invalid file references are reported as errors.
Check that the 'Release' tag in the RPM spec file includes the %{?dist} directive.
Ensure the spec file name conforms to the NAME.spec naming format.
Ensure compliance with modularity build and packaging policies (only valid for module builds, no-op otherwise).
Check minimum required Java bytecode version in class files, report bytecode version changes between builds, and report if bytecode versions are exceeded. The bytecode version is vendor specific to releases and defined in the configuration file.
Report changed files from the before build to the after build. Certain file changes will raise additional warnings if the concern is more critical than just reporting changes (e.g., a suspected security impact). Any gzip, bzip2, or xz compressed files will have their uncompressed content compared only, which will allow changes through in the compression level used. Message catalog files (.mo) are unpacked and compared using diff(1). Public C and C++ header files are preprocessed and compared using diff(1). Any changes with diff output are included in the results.
Report files that have moved installation paths or across subpackages between builds. Files moved with a security path prefix generate special reporting in case a security review is required. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Report removed files from the before build to the after build. Shared libraries get additional reporting output as they may be unexpected dependency removals. Files removed with a security path prefix generate special reporting in case a security review is required. Source RPMs and debuginfo files are ignored by this inspection. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Report added files from the before build to the after build. Debuginfo files are ignored as are files that match the patterns defined in the configuration file. Files added to security paths generate special reporting in case a security review is required. New setuid and setgid files raise a security warning unless the file is in the fileinfo list. Rebased packages report these findings at the INFO level while non-rebased packages report them at the VERIFY level or higher.
Report Source archives defined in the RPM spec file changing content between the before and after build. If the source archives change and the package is on the rebaseable list, the change is reported as informational. Otherwise the change is reported as a rebase of the package and requires inspection.
Report files and directories owned by unexpected users and groups. Check to make sure executables are owned by the correct user and group. If a before and after build have been specified, also report ownership changes.
For all shell scripts in the build, perform a syntax check on it using the shell defined in its #! line (shell must also be listed in shell section of the configuration data). If the syntax check returns non-zero, report it to the user and return a combined stdout and stderr. If comparing two builds, perform the previous check but also report if a previously bad script is now passing the syntax check.

Loading…

User avatar None

String updated in the repository
Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
Perform some RPM header checks. First, check that the Vendor contains the expected string as defined in the configuration file. Second, check that the build host is in the expected subdomain as defined in the configuration file. Third, check the Summary string for any unprofessional words. Fourth, check the Description for any unprofessional words. Lastly, if there is a before build specified, check for differences between the before and after build values of the previous RPM header values and report them.
a year ago
Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Placeholders: Hungarian, Swedish, Russian

Reset

Glossary

English English
No related strings found in the glossary.

14709167 String information

Flags
placeholders:RPM:Vendor:Description:Summary, read-only
Source string location
include/inspect.h:1359
String age
a year ago
Last updated
10 months ago
Source string age
a year ago
Translation file
rpminspect.pot, string 4