Well, someone in the german forum posted about a compiler error when emerging glibc: gethstent_r.c:16:2: invalid preprocessing directive: #ynclude gethstent_r.c:19:2: invalid preprocessing directive: #defyne gethstent_r.c:20:2: invalid preprocessing directive: #tefine gethstent_r.c:21:2: invalid preprocessing directive: #tefine Now that's right, since there are no pre-processor directives called "#ynclude" or "#tefine" (They are named "#include" and "#define"). To be sure I've tried to emerge glibc, wait until emerge extracts the sources and applieds all the patches. Then I've stopped emerge (<STRG> + z) and searched in its temp directory for the file "gethstent_r.c". For me the file looks correct (No misspeled directives). To be sure I've also executed the following statement: find /var/tmp/portage/glibc-2.3.5-r1 -exec grep "ynclude" {} \; which gives me no results. Don't take me for paranoid, but I think one of the distfile servers has been hacked (At least I can't think of another reason for misspelled pre-processor dirctives in the source). The related thread can be found here: http://forums.gentoo.org/viewtopic-t-379057.html Mfg Sino
Would you attach the Manifest and digest file please!? Which mirrors are you using?
(In reply to comment #1) > Would you attach the Manifest and digest file please!? Which mirrors are you using? That's are the servers from the user "emerge --info" output: GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" Mfg Thomas
My last answer was obviously not delivered (Just pressed reply in my mail client). Therefore I'll write here again: 1. The problem wasn't for me, it was posted by someone in the german part of the gentoo forums. But've replied he should post the manifest and digest files. 2. There seems to be a related problem in this thread: http://forums.gentoo.org/viewtopic-t-379071-highlight-.html (User complains that emerge removes glibc when upgrading gcc, vmware or wine) Mfg Thomas
CC'ing Lance.
could you try and be more specific about which mirror it is? try one at a time and tell me which one pukes on you. also, like Carsten asked, can you please post a manifest and digest of the files also? i want to confirm if its just a bad download by that mirror or if we need to do further investgiation
Now, as I said in my last post, that isn't a problem for me, it was reported by two other users in the gentoo forums (So I can't post the digest or manifest files). Since both users has problems with different packages (One complains about bad source for glibc, the other complains that glibc gets unmerged when upgrading gcc or wine) I assumed it's a problem with bad ebuilds and therefore a problem with an rsync server (Which updates your portage tree). Anyway, I've noticed that both users are regsitered for just one or two days and for both users it was their first post. And none of them answers anymore (Still waiting for 4 or 5 hours now (And normal when having such a problem a user would reply fast, wouldn't he ?)). I also wonder why nobody else encountered such problems. So perhaps somebody tried to make a joke !? Hmm ... think I'll try some rsync mirrors to sync my portage tree .. but as I wait longer and longer for an answer of that users that less I think of a real problem. Mfg Thomas
The second problem with glibc getting unmerged is almost certainly some sort of problem the user has created for themselves. I imagine we'd be hearing from more than one person if there was an rsync mirror with broken ebuilds that were unmerging glibc. In either case, the persons need to file a bug. Forums are not the place for bug reports. That's why we put jforman through hell maintaining bugzilla.
(In reply to comment #7) > The second problem with glibc getting unmerged is almost certainly some sort of > problem the user has created for themselves. I imagine we'd be hearing from more > than one person if there was an rsync mirror with broken ebuilds that were > unmerging glibc. > > In either case, the persons need to file a bug. Forums are not the place for bug > reports. That's why we put jforman through hell maintaining bugzilla. You're right a forum is not the right place. But since those users were new to the forum and perhaps don't know about bugs.gentoo.org, I've started a new bug report for them. And as I mentioned above I've thought about a hacked rsync mirror since both described problems are result of a bad ebuild - The bad source for the glibc must normally recognized by emerge when doing the md5 check and therefore I was sure a wrong md5 sum has been placed - Unmerging glibc when emerging gcc etc. must also be a problem of a bad ebuild (Is there a way to place an statement in an ebuild to tell emerge to unmerge a package ? I wasn't sure but can think of another thing causing that problem.) Anyway, I'm sorry if there's no real problem and just one stupid user has tried to make a joke :( Mfg Thomas
If this was truly a "hacked" server, then the attacker would have needed to hack both a) a distfile mirror and b) an rsync mirror and then c) made sure that the user was using both of those servers in his make.conf. The chances of all three being true are very remote. As such, I suspect this is something else entirely.
(In reply to comment #9) > If this was truly a "hacked" server, then the attacker would have needed to hack > both a) a distfile mirror and b) an rsync mirror and then c) made sure that the > user was using both of those servers in his make.conf. > Haven't wrote any own ebuilds yet and don't really know much about them, but I've noticed that in some of them the location for the distfile is stored in (SRC_URI="..."). Therefore an hacker only have to hack an rsync mirror and place a source URL in the ebuilds. Or am I wrong ? Anyway, nobody of the both users having problems have answered to now, so I think it was just a stupid joke. Sorry for the work you have had with this bug report. Mfg Thomas
(In reply to comment #9) > both a) a distfile mirror and b) an rsync mirror and then c) made sure that the > user was using both of those servers in his make.conf. A number of mirrors serve both as distfile and rsync mirror afaik, so a) and b) can be one and the same factor. Given that an attacker easily can change eclasses without much notice it could also be only factor b). Not that unlikely and personally I'm only waiting that we get bitten, because of being slow implementing a signed portage tree.
security@g.o handles portage security, not infra security. Reassigning
Is this reproducable for anyone else? Or just a case of a bad memory stick?
(In reply to comment #11) > A number of mirrors serve both as distfile and rsync mirror afaik, so a) and b) > can be one and the same factor. Given that an attacker easily can change > eclasses without much notice it could also be only factor b). > > Not that unlikely and personally I'm only waiting that we get bitten, because of > being slow implementing a signed portage tree. If you'd look at his settings he was using a rrdns for his rsync, and none of the distfile mirror IPs overlap. Kurt's comment is still valid. -C
Closing due to inactivity. Please re-open if its still an issue.
