lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 10 Jul 2013 19:11:53 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: Michal Marek <mmarek@...e.cz> Cc: Jan Beulich <JBeulich@...e.com>, dt.tangr@...il.com, Geert Uytterhoeven <geert@...ux-m68k.org>, James Hogan <james.hogan@...tec.com>, Christian Kujau <lists@...dbynature.de>, Mike Marciniszyn <mike.marciniszyn@...el.com>, Nicolas Dichtel <nicolas.dichtel@...nd.com>, robert.richter@...xeda.com, "Yaakov (Cygwin/X)" <yselkowitz@...rs.sourceforge.net>, zzs0213@...il.com, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [GIT] kbuild changes for v3.11-rc1 On Wed, Jul 10, 2013 at 6:37 AM, Michal Marek <mmarek@...e.cz> wrote: > > please pull the kbuild bits for v3.11-rc1: THIS IS SOME HORRIBLY BROKEN CRAP. "make install" and "make modules_install" ABSOLUTELY MUST NOT MODIFY THE SOURCE TREE. Dammit, this has happened before, and it was broken then, and it is broken now. If they do, they are *F*CKING*BROKEN*. They are really really badly broken, since we do *not* want root to write to the source tree. You should build the tree as a normal user, and install as root, and dammit, if there are any root-owned files in the source tree after that "make install", then the build system is broken. You need to start being more careful. And I would seriously suggest you start doing some explicit testing for this. You can do things like "find . -user root", and if that shows a single file in the kernel tree after a "make [modules_]install", then there's a problem. Commit d2aae8477cd00325bb7c7c7e95be488088900c48 is broken. It causes root to re-write "include/config/kernel.release". There is no excuse for this. That commit is shit. There's no way in hell that "make modules_install" should ever rebuild anything, so adding that kind of dependency is fundamentally wrong and broken. And that totally crap commit is even marked for stable. I hate hate hate when this kind of crap happens. In this case I noticed it because the git commit abbreviation rules are different for root and for a normal user on my machine, and so running that version-generation script as root actually GIVES THE WRONG ANSWER - it gives a different version than the one the kernel was actually built with. So no. We do *not* start adding random dependencies to the install targets. Because they damn well should not be building anything. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists