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_64rtld 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. :) 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? 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.
So I am not too paranoid. Ah, BTW, the number of files downloaded for me is 75 (counting the occurrences of "wget" in the log).
OK, very good. you count via "wget" occurrence , I count via "ls -1", my direct result was 80 and I subtracted the 3 coming from book directives. same range (77 <-> 75, close enough in our context). IMHO, this value (77|75) is, and by far, way too high (we can not say: all components are build from scratch). OK, guys, I know we are all busy trying to close 9.0 (me too), but is there a way to say "our" libreoffice generated binaries are not compromised... Huge question :( . After Pierre contribution I asked to google about libreoffice compromise, not much result...but this one... https://www.linuxquestions.org/questions/linux-software-2/libreoffice-6-and-opengl-rendering-problem-4175652226/ ;----------------------- 04-16-2019, 07:58 AM [...]Please note, I'm not saying Libreoffice is compromised. I'm saying that possibly the whole ecosystem is (not everywhere, not every project) and that Libreoffice seems like one more thing that has taken a turn away from reliability. It's not about attributing malice or bad design, I'm sure that (speaking very broadly) it's a little of both. Libreoffice might just be using a library that has its direction/reliability compromised. That wouldn't be their fault any more than it's mine for trying to use Libreoffice.
;----------------------------- -- seen "Linux from scratch" and looking for ISO files www.osukiss.org
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
