Bug 6106

That's expected.

rpm -q --scripts indexhtml
postinstall scriptlet (using /bin/sh):
# adapt to the LANG and PRODUCT_ID of the installation
mkdir -p  /usr/share/indexhtml
sed -i  -e "s/#PRODUCT_ID/`cat /etc/product.id`/" \
        -e "s/#LANG/${LC_NAME/[-_]*}/g" \
        /usr/share/indexhtml/index.html

It automatically customizes the installation, to match
the selected language.

CC: (none) => davidwhodgins

Then it becomes a bug in the package manager itself, because it depreciates the value of the audit when you have to try to figure out which exceptions are legitimate ones and which are real issues.  If there then is no way for `rpm -V` to validate this file, it should be white listed internally within the package manager system OR marked as configuration files are (not AS a configuration file, but perhaps with an 'x' instead of a 'c' so that it can be recognized as an exception) so that one doesn't have to waste time sorting out real problems from ghosts.  I would expect `rpm -Va` output to be clean other than 'c' config files which obviously can't be vetted with a simple automated audit.  I realize I am asking for the stars, the sun and the moon here, but this is Mageia and I am seeing and appreciating the intense magic so far and have some really great expectations for the future.  But in all sincerity, Dave, thanks for the explanation.  - George

I would also add here that the Mageia team has done a REALLY great job on the `rpm -Va` output as it is.  It is night and day better than what I experienced with Mandriva and that is VERY appreciated.  It is REALLY cleaned up.

george, can you adjust the summary then ? (it's a out of my knowledge to make a understand one)

thanks

I'll give it a try.  It makes sense to me, that any file that will
be modified by a scriptlet in the rpm package, should be marked
as a config file, so that the modifications don't trigger flagging
by rpm -V.

Summary: This package fails `rpm -V indexhtml` from the point of installation. => Files modified by scriplets should be marked as config files.

Dave,  Actually, taking a closer look at this, I think it more resembles an html documentation file, since it forms the template for what comes up as the default home page when the user first opens their browser.  Flagging it as %doc would do the job in terms of saving the sys admin of wasting time chasing a rabbit.  Let me know what you think.  Either %config or %doc would work for me.  Thanks, George

ok thanks

CC: (none) => dmorganec, thierry.vignaud
Source RPM: indexhtml-1-7.mga2.noarch.rpm => urpmi, rpm

Just so we are clear on this.  The problem remains with indexhtml, not with the urpmi or rpm.  Both urpmi and rpm currently support flagging a package as either %config or %doc.  Personally, I think this package is actually an html document.  It is, after all just a local web page created for the users information.  So I think the indexhtml package itself needs to be changed to reflect that which would provide a "d" in the type field which would distinguish it from binaries that need to be patrolled for security issues by `rpm -Va`.  Thanks guys!  - George

Isn't there a script the checks uploaded rpm packages for "correctness"?  If it
could be modified to look for files updates in a scriptlet, it could also check
to ensure its either a doc or config file.

I think the problem with trying to automate a solution would be that indexhtml is just one example of this sort of problem.  A few other examples floating around:

1)  Typically fonts.dir and fonts.scale (and fonts.map, encodings.dir, etc) files are big offenders.  These are probably populated by a script and would probably be picked up by a "correctness" script.  But these are clearly %config files as opposed to %doc files.  So the script could probably flag these, but there would be a question as to whether the script could correctly determine whether they fit into a %config flag category or a %doc tag category (not to mention a %ghost, %license, or %readme flag category).  However a script would probably be useful to simply flag the problem.

2)  Another offender would be data files where the data gets modified dynamically by external inputs.  Not sure how these would be categorized, perhaps as %ghost files?

3)  Then there is /usr/bin/startx.  This would appear at first glance to be a binary, but it is actually a shell script WITH the following header:

# This is just a sample implementation of a slightly less primitive
# interface than xinit.  It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default.  The system xinitrc should probably do things like check
# for .Xresources files and merge them in, start up a window manager,
# and pop a clock and several xterms.
#
# Site administrators are STRONGLY urged to write nicer versions.

Note ESPECIALLY the last comment.  It makes this clearly a %config file masquading as a shell script.  How to deal with this one?  Obviously, IF it is modified by a rogue intruder, that could pose a danger.  Does that mean I need to check it each time it shows up on `rpm -Va`?  Too bad there isn't a way for this script to be static and draw LIMITED input from an external config file instead, thus allowing for a measure of protection against malware.  In the same vein we find various perl and python scripts that get dynamically configured.

Just some thoughts on the larger scope of the problem.

- George

Ok. Let's just fix the index.html file for now, as that's the only file flagged
for this package.

This has nothing to do with urpmi.
This is a packaging issue.

CC: thierry.vignaud => (none)
Source RPM: urpmi, rpm => indexhtml

Hi, thanks for reporting this bug.
As there is no maintainer for this package I added the committers in CC.

Keywords: (none) => Triaged
CC: (none) => ennael1, mageia, pierre-malo.denielou, stormi

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD