Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 08:07, Maxim Koltsov wrote: 1) Do you agree with adding new category? Not really... are you going to add any more packages? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 08:07, Maxim Koltsov wrote: 1) Do you agree with adding new category? Not really... are you going to add any more packages? Yes, definitely. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu On 06/03/2013 08:07, Maxim Koltsov wrote: 1) Do you agree with adding new category? Not really... are you going to add any more packages? It's very probable, yes. Also I think 60 packages is quite big number, as we have many categories with 20 or even less packages. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 10:15, Maxim Koltsov wrote: It's very probable, yes. Also I think 60 packages is quite big number, as we have many categories with 20 or even less packages. The fact that we made mistakes in the past does not justify making more mistakes. How many more are you expecting? (and the answer many! is not going to fly, if anything would make me more convinced we shouldn't do this). -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
On Wed, Mar 6, 2013 at 10:15 AM, Maxim Koltsov maksbo...@gentoo.org wrote: Not really... are you going to add any more packages? It's very probable, yes. Also I think 60 packages is quite big number, as we have many categories with 20 or even less packages. It's not *just* the number of packages. I, for one, had never even heard of it except via your email to this list. And having looked at the site, I don't really see why people would want to use it, anyway. Not that you have to explain it, but that leads me to wonder if (a) there are other Gentoo devs who would maintain this stuff if you become disinterested, and (b) how many users there even are for LeechCraft-related packages. FWIW, in Debian's popcon, there seems to be about 6 users who have LeechCraft installed (which ranks it slightly south of 70,000th). Cheers, Dirkjan
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: How many more are you expecting? Six components are ready to be packaged in the nearest future, four are being developed, and there are plans for, well, like a dozen more. Also, keeping stuff in one category allows splitting several huge ebuilds like leechcraft-azoth into more smaller ones. Each use flag there is basically a separate plugin, and as plugins could be built separately, there is no need in recompiling all of them just to install/uninstall/etc a single one. That single azoth thingie adds around 30 more packages. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 6 March 2013 15:07, Maxim Koltsov maksbo...@gentoo.org wrote: Hi, Currently there are 61 leechcraft packages in tree scattered across several categories. We propose to move them to one new category to make maintaining easy as well as rsync --exclude'ing. So, two questions: 1) Do you agree with adding new category? I don't see why not. 2) How should we call it: app-leechcraft, leechcraft-base or anything else? Yes, something like that. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] [RFC] New category for LeechCraft
On Wednesday 06 March 2013 10:33:58 Diego Elio Pettenò wrote: The fact that we made mistakes in the past does not justify making more mistakes. Um, what are you talking about, too many categories? I am afraid, there is no fix in the form of lets not add any. Every commits summary message has at least 3x more added packages vs removed ones. This stuff has to go somewhere and some categories are becoming way overfilled I'd say. At the same time I do agree that the present flat list of super-sub categories is not scaling well either (OTOH it is still nicer than some of the 200+ large categories of present). May be it is time to scratch the flat list of categories and finally go into a full tree mode? I.e.: app-* = app/accessibility /admin etc, and subdivide where necessary? (e.g. app/admin/eselect/ would be just one such beneficiary). Just a thought..
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Dirkjan Ochtman d...@gentoo.org: On Wed, Mar 6, 2013 at 10:15 AM, Maxim Koltsov maksbo...@gentoo.org wrote: Not that you have to explain it, but that leads me to wonder if (a) there are other Gentoo devs who would maintain this stuff if you become disinterested Yep, Pinkbyte is also co-maintaining, and in case of something terrible I could try becoming a maintainer, since I'm also a long-time Gentoo user :) (b) how many users there even are for LeechCraft-related packages. Summer estimates are around 10k more or less permanent users. FWIW, in Debian's popcon, there seems to be about 6 users who have LeechCraft installed (which ranks it slightly south of 70,000th). Debian's popcon is slightly irrelevant as LC isn't available in Debian repos. -- Georg Rudoy LeechCraft — http://leechcraft.org
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 13:04, George Shapovalov wrote: I am afraid, there is no fix in the form of lets not add any. Every commits summary message has at least 3x more added packages vs removed ones. I'm just saying that I wouldn't want to create a category for ten packages. If we're talking ~100 I'm fine with it. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
On Wed, Mar 6, 2013 at 9:06 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: I'm just saying that I wouldn't want to create a category for ten packages. If we're talking ~100 I'm fine with it. Can't say I'm likely to be a leechcraft user, but the original proposal indicated they were up to 60 now, and had at least 10-20 more in the works. I don't think a category is unreasonable, and if at some point in time popularity wanes and it needs treecleaning it makes the whole task that much easier... Rich
[gentoo-dev] [PATCH 1/3] multibuild: introduce generic multibuild_copy_sources.
The new function can be used to create per-variant copies of source
trees. Code based on python_copy_sources from python-r1.
---
gx86/eclass/multibuild.eclass | 21 +
1 file changed, 21 insertions(+)
diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index 8ccd3b6..65f3926 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -205,6 +205,27 @@ multibuild_for_best_variant() {
multibuild_foreach_variant ${@}
}
+# @FUNCTION: multibuild_copy_sources
+# @DESCRIPTION:
+# Create per-variant copies of source tree. The source tree is assumed
+# to be in ${BUILD_DIR}, or ${S} if the former is unset. The copies will
+# be placed in directories matching BUILD_DIRs used by
+# multibuild_foreach().
+multibuild_copy_sources() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ local _MULTIBUILD_INITIAL_BUILD_DIR=${BUILD_DIR:-${S}}
+
+ einfo Will copy sources from ${_MULTIBUILD_INITIAL_BUILD_DIR}
+
+ _multibuild_create_source_copy() {
+ einfo ${impl}: copying to ${BUILD_DIR}
+ cp -pr ${_MULTIBUILD_INITIAL_BUILD_DIR} ${BUILD_DIR} || die
+ }
+
+ multibuild_foreach_variant _multibuild_create_source_copy
+}
+
# @FUNCTION: run_in_build_dir
# @USAGE: argv...
# @DESCRIPTION:
--
1.8.1.5
[gentoo-dev] [PATCH 3/3] multilib-build: introduce multilib_copy_sources.
---
gx86/eclass/multilib-build.eclass | 14 ++
1 file changed, 14 insertions(+)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index c29b5df..66fb5a6 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -190,5 +190,19 @@ multilib_check_headers() {
fi
}
+# @FUNCTION: multilib_copy_sources
+# @DESCRIPTION:
+# Create a single copy of the package sources for each enabled ABI.
+#
+# The sources are always copied from initial BUILD_DIR (or S if unset)
+# to ABI-specific build directory matching BUILD_DIR used by
+# multilib_foreach_abi().
+multilib_copy_sources() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ local MULTIBUILD_VARIANTS=( $(multilib_get_enabled_abis) )
+ multibuild_copy_sources
+}
+
_MULTILIB_BUILD=1
fi
--
1.8.1.5
[gentoo-dev] [PATCH 2/3] python-r1: use multibuild_copy_sources.
---
gx86/eclass/python-r1.eclass | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass
index 934f32d..36b20dc 100644
--- a/gx86/eclass/python-r1.eclass
+++ b/gx86/eclass/python-r1.eclass
@@ -348,34 +348,22 @@ python_gen_cond_dep() {
# @FUNCTION: python_copy_sources
# @DESCRIPTION:
-# Create a single copy of the package sources (${S}) for each enabled
-# Python implementation.
+# Create a single copy of the package sources for each enabled Python
+# implementation.
#
-# The sources are always copied from S to implementation-specific build
-# directories respecting BUILD_DIR.
+# The sources are always copied from initial BUILD_DIR (or S if unset)
+# to implementation-specific build directory matching BUILD_DIR used by
+# python_foreach_abi().
python_copy_sources() {
debug-print-function ${FUNCNAME} ${@}
_python_validate_useflags
+ _python_check_USE_PYTHON
- local impl
- local bdir=${BUILD_DIR:-${S}}
-
- debug-print ${FUNCNAME}: bdir = ${bdir}
- einfo Will copy sources from ${S}
- # the order is irrelevant here
- for impl in ${PYTHON_COMPAT[@]}; do
- _python_impl_supported ${impl} || continue
-
- if use python_targets_${impl}
- then
- local BUILD_DIR=${bdir%%/}-${impl}
+ local MULTIBUILD_VARIANTS
+ _python_obtain_impls
- einfo ${impl}: copying to ${BUILD_DIR}
- debug-print ${FUNCNAME}: [${impl}] cp ${S} =
${BUILD_DIR}
- cp -pr ${S} ${BUILD_DIR} || die
- fi
- done
+ multibuild_copy_sources
}
# @FUNCTION: _python_check_USE_PYTHON
--
1.8.1.5
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 15:23, Rich Freeman wrote: Can't say I'm likely to be a leechcraft user, but the original proposal indicated they were up to 60 now, and had at least 10-20 more in the works. I don't think a category is unreasonable, and if at some point in time popularity wanes and it needs treecleaning it makes the whole task that much easier... I would have said no for 61 (as I would have expected them to wane, as you said) — for 100 I'm fine, if that's happening. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 15:23, Rich Freeman wrote: Can't say I'm likely to be a leechcraft user, but the original proposal indicated they were up to 60 now, and had at least 10-20 more in the works. I don't think a category is unreasonable, and if at some point in time popularity wanes and it needs treecleaning it makes the whole task that much easier... I would have said no for 61 (as I would have expected them to wane, as you said) — for 100 I'm fine, if that's happening. So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 6 March 2013 15:12, Maxim Koltsov maksbo...@gentoo.org wrote: 2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 15:23, Rich Freeman wrote: Can't say I'm likely to be a leechcraft user, but the original proposal indicated they were up to 60 now, and had at least 10-20 more in the works. I don't think a category is unreasonable, and if at some point in time popularity wanes and it needs treecleaning it makes the whole task that much easier... I would have said no for 61 (as I would have expected them to wane, as you said) — for 100 I'm fine, if that's happening. So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ I have no problem with the new category. We recently created a new category for the Qt packages which has around 20 packages in it, so I am not sure why Diego wants more than 100 packages for the new category. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 16:19, Markos Chandras wrote: I have no problem with the new category. We recently created a new category for the Qt packages which has around 20 packages in it, so I am not sure why Diego wants more than 100 packages for the new category. I wasn't too happy about that either, if you remember. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
On 06/03/2013 16:12, Maxim Koltsov wrote: So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. Then go for it. I'd suggest just app-leechcraft -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [RFC] New category for LeechCraft
2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 16:12, Maxim Koltsov wrote: So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. Then go for it. I'd suggest just app-leechcraft Thanks. Do i have to do anything more that add it to profiles/categories and mkdir? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Regards, Maxim.
Re: [gentoo-dev] [RFC] New category for LeechCraft
On Wed, 6 Mar 2013 20:05:51 +0400 Maxim Koltsov maksbo...@gentoo.org wrote: 2013/3/6 Diego Elio Pettenò flamee...@flameeyes.eu: On 06/03/2013 16:12, Maxim Koltsov wrote: So, what have we decided? I'm pretty sure it'll go up to 100 quite soon. Then go for it. I'd suggest just app-leechcraft Thanks. Do i have to do anything more that add it to profiles/categories and mkdir? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ No, just make sure it is a separate commit according to http://devmanual.gentoo.org/profiles/categories/index.html. As for moving packages, don't forget to do this as well: Grep the entire Portage tree to correct files that block / depend on it, correct profile files that list it and also specify `move oldcat/oldpkg newcat/newpkg` instructions in the profiles/updates directory according to http://devmanual.gentoo.org/profiles/updates/index.html. With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
Hi guys,
I normally hang out on irc on #gentoo-kernel and a bunch of other #gentoo-*
channels. I stumble across the discussion of bug 447352 [1] that was
reported by a user that was enforcing module signatures on the kernel. This
made me to this patch (I talked to Mike before doing this).
Signed kernel modules require that the kernel is compiled with
CONFIG_MODULE_SIG=y so that during compilation, the public key hash is
stored in the kernel so that it can be verified later when insmod'ing an
external module. There is no problem with in-tree modules, this are sign
correctly and loaded, the problem is with out-of-the-tree modules installed
by portage; this ones are not signing ware.
So this patch adds a new USE flag to the linux-mod.eclass named
module-signing. We enabled, it will check if the user has selected all
the correct config options in the kernel, and optionally, where are the
private and public parts of the key so that the module is signed and
install time. If any of this fails, the installation of the module is
aborted.
From the end user perspective, if he wants to add support for this, all he
has to do is enable CONFIG_MODULE_SIG in the kernel. If no keys are found
during the build, it will be generated one. If one wants to create a key
himself, it's also possible to use this key, he just has to name it
signing_key.priv and siging_key.x509 and put it under /usr/src/linux.
After the kernel is compiled, this keys can be moved elsewhere and the path
to them specified in make.conf under the vars KERNEL_MODSECKEY and
KERNEL_MODPUBKEY.
Patch below for review, discussion and testing.
Thanks,
Carlos Silva
[1] https://bugs.gentoo.org/show_bug.cgi?id=447352
--- linux-mod.eclass 2012-09-15 16:31:15.0 +
+++ linux-mod.eclass 2013-03-06 15:57:25.808173694 -0100
@@ -125,9 +125,10 @@
inherit eutils linux-info multilib
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install
src_compile pkg_postrm
-IUSE=kernel_linux
+IUSE=module-signing kernel_linux
SLOT=0
-RDEPEND=kernel_linux? ( virtual/modutils )
+RDEPEND=kernel_linux? ( virtual/modutils )
+ module-signing? ( dev-lang/perl dev-libs/openssl )
DEPEND=${RDEPEND}
sys-apps/sed
kernel_linux? ( virtual/linux-sources )
@@ -208,6 +209,34 @@
fi
}
+
+# internal function
+#
+# FUNCTION: check_module_signing
+# DESCRIPTION:
+# Checks for KERNEL_MODSECKEY, KERNEL_MODPUBKEY and verifies the files
exists
+check_module_signing() {
+ if ! use module-signing; then
+ return 1
+ fi
+
+ # Check that the configuration is correct
+ KERNEL_MODSECKEY=${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}
+ KERNEL_MODPUBKEY=${KERNEL_MODPUBKEY:-${KV_DIR}/signing_key.x509}
+ if [ ! -z ${KERNEL_MODSECKEY}x -a ! -e ${KERNEL_MODSECKEY} ]; then
+ eerror KERNEL_MODSECKEY points to a missing file:
+ eerror ${KERNEL_MODSECKEY}
+ die Invalid KERNEL_MODSECKEY
+ fi
+ if [ ! -z ${KERNEL_MODPUBKEY}x -a ! -e ${KERNEL_MODPUBKEY} ]; then
+ eerror KERNEL_MODPUBKEY points to a missing file.
+ eerror ${KERNEL_MODPUBKEY}
+ die Invalid KERNEL_MODPUBKEY
+ fi
+
+ return 0
+}
+
# internal function
#
# FUNCTION: update_depmod
@@ -581,6 +610,10 @@
return
fi
+ if use module-signing; then
+ CONFIG_CHECK+=${CONFIG_CHECK} MODULE_SIG
+ fi
+
linux-info_pkg_setup;
require_configured_kernel
check_kernel_built;
@@ -663,7 +696,7 @@
# This looks messy, but it is needed to handle multiple variables
# being passed in the BUILD_* stuff where the variables also have
- # spaces that must be preserved. If don't do this, then the stuff
+ # spaces that must be preserved. If dont do this, then the stuff
# inside the variables gets used as targets for Make, which then
# fails.
eval emake HOSTCC=\$(tc-getBUILD_CC)\ \
@@ -710,6 +743,12 @@
srcdir=${srcdir:-${S}}
objdir=${objdir:-${srcdir}}
+ if check_module_signing; then
+ ebegin Signing module ${modulename}
+ ${KV_DIR}/scripts/sign-file ${KERNEL_MODSECKEY} ${KERNEL_MODPUBKEY}
${objdir}/${modulename}.${KV_OBJ}
+ eend $?
+ fi
+
einfo Installing ${modulename} module
cd ${objdir} || die ${objdir} does not exist
insinto /lib/modules/${KV_FULL}/${libdir}
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
-Original Message- From: Carlos Silva r3...@r3pek.org To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing Date: Wed, 6 Mar 2013 18:25:38 -0100 @@ -663,7 +696,7 @@ # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have - # spaces that must be preserved. If don't do this, then the stuff + # spaces that must be preserved. If dont do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. eval emake HOSTCC=\$(tc-getBUILD_CC)\ \ ^^ Why did you remove the ' in don't ? Seems like it was an mistake? The rest looks fine to me, maybe Ryao can chime in, I know he was interested in module signing. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 6:32 PM, Steev Klimaszewski st...@gentoo.org wrote: # This looks messy, but it is needed to handle multiple variables # being passed in the BUILD_* stuff where the variables also have - # spaces that must be preserved. If don't do this, then the stuff + # spaces that must be preserved. If dont do this, then the stuff # inside the variables gets used as targets for Make, which then # fails. eval emake HOSTCC=\$(tc-getBUILD_CC)\ \ ^^ Why did you remove the ' in don't ? Seems like it was an mistake? The rest looks fine to me, maybe Ryao can chime in, I know he was interested in module signing. Yeah, mistake there. I noticed after I sent the email ;) Removed the ' so that vim syntax wouldn't freak. Disregard that part.
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? //Peter
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 8:39 PM, Peter Stuge pe...@stuge.se wrote: Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? It's where the kernel build system picks them. They only have to be there to build the kernel, nothing else. After the kernel is built, and the modules compiled and signed against that keys, they can even be removed from the system.
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? It's where the kernel build system picks them. Are you sure? I find that hard to believe? Even if I tell an external module to build against a source tree in ~/linux/ the Makefiles will go to look for the keys in /usr/src/linux/ ? They only have to be there to build the kernel, nothing else. I'm not talking about end users, by users I mean those who use the key files to build kernels and modules. //Peter
Re: [gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing
On Wed, Mar 6, 2013 at 9:14 PM, Peter Stuge pe...@stuge.se wrote: Carlos Silva wrote: If one wants to create a key himself, it's also possible to use this key, he just has to name it signing_key.priv and siging_key.x509 and put it under /usr/src/linux. Do you know if this is a sane default? Where do most users of signed modules store keys so far? It's where the kernel build system picks them. Are you sure? I find that hard to believe? Even if I tell an external module to build against a source tree in ~/linux/ the Makefiles will go to look for the keys in /usr/src/linux/ ? OK, my bad here. The kernel build system looks for them on the root of the kernel source. To build modules, they can be anywhere as long as you have the correct path set on make.conf: KERNEL_MODSECKEY=/path/to/privkey KERNEL_MODPUBKEY=/path/to/pubkey This only works for modules. They only have to be there to build the kernel, nothing else. I'm not talking about end users, by users I mean those who use the key files to build kernels and modules. See above. I even read online that a best practice would be to generate a new set of keys on every kernel build actually deleting the keys after the kernel and external modules are compiled.
