Jean-Marc Pigeon via blfs-dev wrote:
On 08/26/2019 09:23 AM, Pierre Labastie via blfs-dev wrote:
Jean-Marc Pigeon via blfs-dev wrote:
Hello guys (Ken, DJ and Pierre),
Thanks to have bring your "pint of brain juice".
On 08/26/2019 01:50 AM, Pierre Labastie via blfs-dev wrote:
On 25/08/2019 21:49, Jean-Marc Pigeon via blfs-dev wrote:
Hello guys (and girls).
I need your wisdom... Let's share a pint of brain juice.
Here's the drill.
context:
- LFS-9.0rc (linux 5.2.8, glibc-2.30, gcc-9.2.0)
- I am able to build libreoffice-6.3.0.4 with all
bells and whistles
(lets assume I didn't really goofed with the book directives).
I am using zypper + rpm as my own packages management toolkit
and rpm say:
Error: Failed dependencies:
rtld(GNU_HASH) is needed by
libreoffice-6.3.0.4-1.53.249.ok_9.0.x86_64
rtld is the run time linker of glibc (the loader of .so libraries).
It is
certainly installed on your system, otherwise nothing could run
(unless you
have built everything statically). So, for some reason, it seems that
glibc,
or part of glibc, is not known to rpm (I do not know much about rpm)
on your
system. But in that case, it is amazing that you haven't seen that
before.
Could it be that you have taken an rpm spec file from some distro,
and that
you have omitted to remove some dep when editing it?
About the drill, keep in mind,
- the all smash (the >800 packages, glibc included) are
recompiled every time.
this means discrepancies between glibc and compiled binaries
seems to me hardly plausible.
- The book directives are used within the "specs file" (build and
install sequences), trying my best not to diverge from book
directives
(using book patches, configure paramaters, etc.) Please see the
rpm specs file as MY shell/tool to build LFS+BLFS again and again.
- In the building sequences the only package with this rtld report
is libreoffice.
- libreoffice (as fare I can say) components, once installed, are
nicely working.
- I am not building statically and not using libtools.
- May be I was not specific enough in my original email, RTLD detection
show up in the RPM last building phase (the summary phase, saying,
here is the list of libraries needed when you will install packages)
and (obviously) it become a problem when RPM is used to install
the libroffice package
Ken is proposing the problem is RPM itself, in such case, as
libreoffice
is a rather an heavy package, the build is, may be, going over a limit
of some kind.
I am building the BLFS book within a 30 Gig tmpfs partition
(to have speed), may be I am short about something. I have the feeling
that going over a threshold of some kind will make RPM to crash/give up
in more brutal way. However I'll try my best to prove Ken proposal.
My worry (Hoping to be paranoiac) and this concern the book:
- When rpm is assembling all files (binaries, scripts, conf,
scripts) to do packaging, it scan all added files tracking
what is needed (ex: python, shell (zsh,...), shared libraries, etc.)
and report it in the summary.
This means RPM is detecting something "unexpected".
- Libreoffice Book directives are such, that 77 components are
added/downloaded within external/tarballs directory, this
between the configure phase and the build phase.
(please could you confirm this fact from your side).
We (the book) have no real control/say about those components
(version, contents, function).
- It can not be excluded, there a real binary (trojan, virus,...)
included within the downloaded files. And this binary show
up on RPM scanning phase. Obviously libreoffice, in such case,
is fully functional.
- That why, I am trying to track down the origin of the RTLD,
because if we have an embedded binary "expecting" a
usual/common/old glibc to be fully operational, then
RPM would have this behaviour.
- Please correct me if wrong, but current book directives
have no provision to detect such situation.
- So fare, I am not successful to track down the issue to
a single file, even worth, the "trouble" seems to be in every
libreoffice program.
Do we agree?, libreoffice is the perfect candidate to be
"adjusted" to carry nasty functionality?
So guys, please tell me the rtld problem is an obvious/plain one
and I am just a crazy paranoid.
Hmm, you might not be successful in finding some answer from
this list, since I think almost nobody is familiar enough with rpm
for telling for sure yes or no... You are certainly the best expert
of rpm around. And Ken might be the second.
Pierre, you focus far too much on rpm.
OK, let's put it another way: rpm finds something, but it is hard to
analyze what it is without knowing rpm, and what it does...
:) The age/size of the universe is computed via 5 means (from
the top of my memory, super-nova, Cepheid, infra-red
background noise, etc..), each value is just a random value,
what is important/meaningful is the fact those values are
in the same range and converging.
So, jmp, using RPM, is saying "by the way I am worry we have
strange problem with libreoffice binaries, library may be corrupted".
This is a bold affirmation, is there other tools (do you know other?),
to check/prove/disprove it?
I do not even know what rpm is saying... I mean, which command has
been run and how it has been assessed that it failed. That's why I think
it is for somebody with good rpm knowledge...
This is where this list is important, each of us with is own
"know how". I could be wrong (hopefully), but it is not because
we do not like a result that we can discard it.
What I can add is the if not stripping binaries, sure 30Gb is not
enough for building everything up to libreoffice.
Binaries are stripped, packages are installed on the
"is needed" flag. My "official statement"... when building
(rebuilding) is done (from scratch), books components are
always compiled within the same system context (trying to
be extremely careful about this).
I am not saying I have all BLFS book components (I selected
mate+sddm as graphic skeleton), but results are/must_be
duplicated build after build.
By the way, all (my) rpm packages are freely available and if
you unpack xxxx.src.rpm you will find all the book directives
(ok, you could have slight variation ;) ).
As you said, the book cannot detect whether some of the packages
downloaded during libreoffice build are goofed. But I doubt it
would be possible that nobody else notice: the files are downloaded
and their shasum is checked, so an attacker would have to provide
a file with the same shasum to be able to add something of his own,
or to change the libreoffice tarball itself, but if that person is
able to
do that, it'd much easier to directly change the libreoffice sources.
Hmmm, keep in mind, we are working on the bleeding edge...
we have glibc-2.30 (a brand new one) and very last libreoffice, if
something is embedded in a forgotten addon (build with a previous
glibc), it could show up only now and may be not seen in
few days/weeks (we are the early birds here).
Agreed, I will be very surprised if libreoffice sources itself
are proved to be compromised.
However, this could be touchy, following book directives, libreoffice
application are compromised (assuming there is really something fishy),
Book credibility is at stack here.
Huh, if everything is working, where is the problem?
Just for fun, I can write a diagnostic tool:
----
cat > diagnostic.sh << EOF
#!/bin/bash
if [ 1 = 0 ]; then echo bash is not working
else echo the assertion is false
fi
EOF
-----
What if you do not know what the assertion is when you
run diagnostic.sh?
Of course, rpm is certainly doing something sounder, but without
knowing what, it is hard to tell whether this is serious or just
something which is to be expected in some cases.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
