[Rpm-maint] [rpm-software-management/rpm] Adding namespaces for macros (#246)

[Jeff Johnson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20170630/1c543265/attachment.html>