Macro templating/configuration in RPM has become MUST'VE for building.
Meanwhile, there are no conventions for sorting out the definitions, and the
issues related to loading all macros all the time are getting unmanageable.
E.g. here are the macros defined on a relatively recent Fedora box:
```
$ rpm --version
RPM version 4.13.0.1
$ rpm --showrc | grep '^-' | wc -l
813
```
Almost all of those macros are useful for rpm build templatting and useless
while installing.
(aside)
In fact, many of those rpm build macros (and other macros) can possibly be
invoked while installing, with possibly malicious effects, if the paths used to
load macros are writable (or %{load:...} is expanded within rpm configuration
or a package scriptlet expansion). This is rather too large an attack surface
to audit IMHO, YMMV.
One KISS approach to limiting what macros are loaded is to identify which
macros are needed for installation (e.g. %_dbpath), and which macros are useful
for rpm build's (but not for installation), and load only what is necessary.
A more general approach (quite obvious: many languages have added namespaces to
rationalize de facto organically grown global definitions) would be to invent
an explicit syntax to limit the scope of macro loading and expansions that
includes more than just the RPM build vs install context.
RPM macros already have a "rpmmc" context container that was intended for
namespacing (but never used beyond differentiating the global context from the
RPM CLI override context).
Adding an explicit namespace syntax for an "opt-in" implementation is not much
harder than choosing a syntax. Since macro names are already limited (i.e. must
be >2 characters, must be alphabetic+numeric+underscore, etc), choosing a
namespace separator is largely a choice of a parseable token. E.g. it wouldn't
be impossibly hard to hack in a C++-like namespace identifier based on the
token '::' without breaking the existing usage of ':' in the parser. There are
surely many other unused ASCII characters that could be substituted for '::'
Another implicit approach that seems viable would be to overload an embedded
'_' character within a macro name as if it were a namespace: that "works"
fairly well with, say, per-interpreter macro namespaces like "perl" and
"python" and "ruby", but would require some magic filtering for, say,
self-describing macro names that were created ad hoc like
```
-14: _binaries_in_noarch_packages_terminate_build 1
-14: _empty_manifest_terminate_build 1
-14: _invalid_encoding_terminates_build 0
-14: _missing_build_ids_terminate_build 1
-14: _missing_doc_files_terminate_build 1
-14: _python_bytecompile_errors_terminate_build 1
-14: _unpackaged_files_terminate_build 1
-14: _wrong_version_format_terminate_build 1
```
OTOH RPM is certainly well positioned to be able to identify its own
configuration, and map into a namespace.
I dunno what the best approach is: all the usual "opt-in" vs "opt-out"
approaches, as well as "per-vendor syntax du jour", are viable approaches.
Meanwhile I suggest its time to find a convention that "works" for mapping
macros into namespaces/files.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/246_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
