From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6821118203682357248 X-Received: by 2002:a17:906:551:: with SMTP id k17mr2094006eja.350.1588243363642; Thu, 30 Apr 2020 03:42:43 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:906:1d0c:: with SMTP id n12ls761205ejh.5.gmail; Thu, 30 Apr 2020 03:42:42 -0700 (PDT) X-Google-Smtp-Source: APiQypLIcd2GnIB80j+RyaimhR3H8azSCLgDWC0HGapmI1g0ORmy6hxFNiDiz045H7BFYfHV3/ip X-Received: by 2002:a17:906:8282:: with SMTP id h2mr2183327ejx.250.1588243362900; Thu, 30 Apr 2020 03:42:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588243362; cv=none; d=google.com; s=arc-20160816; b=qL9auLHyJQ8yJ60XCpqB8A1PLL4Hq2TJLqgHzgWLhaxtu1oUBvhsJOdZocVQgbEsNl B8hFTArSfBPXMwKcTPgHPA1tPBbaC7wlLG/nnHKFxDcHjOIA9OYWIC0Jiga0m8cSFaFm hQJezVRB8/ssx98ciexIAHCG/ng9abByvc4lUyN3tC2i7uZd2EMT4YGw+kuV2G/riRjA 2Q8QPKQyvILYYrLZskpMF9/L9jJZa3weMZ9Pehw83LFOQMPSM4IEl49q836D8LLqEJBC Zx8yla/wRJSozXVihRdjSW817WyrRM6fEtxEEQ2coIJT+91qn/DlfkY5E8TLIIW2XsrJ UqEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=xJHRubiDWaqfDbVSudBeaj0H7rNifNU9a7do2ogRTF0=; b=JSr9cMV+54TtxDlNj1uSUoICD+1lVWt1gz6m/J5h/xoMZpCaI77SAOSNB5Nheanc6Q usR2Uu4Uc86wM4gj1yEb5ROvnsWgeIw6JmFvJCBVZdaBDKgBN28NG0GE/HdT6YpLxsx+ XLz6ugPv9iP63EYKELSxcpKEUnCASRgi66MdWOC280LSDRVrgDHNDDBJKNFLqUYtr/hY /+re+WbUSKUrBwTFuFdzypKtT3voyOZJ1tX6KfVzYfxvsLOXAjSLxP+KFTDyNI3a/Ykd YhQRQnoCpFDQyuo22L7IVy2XX8RJ4pdZ3EBxShwYMwonfyRcDKfDlGwTndcZYNzd7Fgy +OiA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id o23si573921edz.4.2020.04.30.03.42.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Apr 2020 03:42:42 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 03UAgfvD009322 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Apr 2020 12:42:41 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.39.178]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 03UAgfGO021095; Thu, 30 Apr 2020 12:42:41 +0200 Date: Thu, 30 Apr 2020 12:42:37 +0200 From: Henning Schild To: Mustafa =?UTF-8?B?WcO8Y2Vs?= Cc: isar-users Subject: Re: signing support for (in-tree and external) kernel modules Message-ID: <20200430124237.292556c8@md1za8fc.ad001.siemens.net> In-Reply-To: References: <9a590808-34da-493f-9ea2-219d17cd87c9@googlegroups.com> <9d4818d5-e884-a600-0504-996042f31e3b@siemens.com> <3a5d776b-3cce-ba0f-cf37-f4e2a0afc65a@gmail.com> <20200429221517.2187f4da@md1za8fc.ad001.siemens.net> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-TUID: 4zA5FTqGqNXv Am Wed, 29 Apr 2020 14:04:38 -0700 (PDT) schrieb Mustafa Y=C3=BCcel : > > =20 > > > >> from where you got CONFIG_MODULE_SIG_FORMAT? CONFIG_MODULE_SIG > > > >> is the trigger to create this binary:=20 > > > >>=20 > > > >> scripts/Makefile:hostprogs-$(CONFIG_MODULE_SIG)+=3D sign-file=20 > > > >> =20 > > > >=20 > > > > I was looking at kernel 5.6.=20 > > > >=20 > > > > Then we likely need multiple condition when to run sign-file > > > > while building an external module.=20 > > > >=20 > > > > And we also need some idea how to deploy the shared keys to all=20 > > > > recipes. If we only talk about two or three, the kernel recipe=20 > > > > could carry the keys as artifacts, and other recipes would > > > > simply link them. But that is not really nice to maintain. We > > > > could, of course, package the keys into linux-headers. > > > > Downside: Someone may then accidentally ship them on a device. > > > > =20 > > >=20 > > > maybe we can use a separate package? e.g. kernel-module-signkeys?=20 > > >=20 > > > normally this package will be only used for building, we can > > > output an error during isar build when someone installs this > > > package to the image (prevents "accidentally ship them on a > > > device")=20 > > >=20 > > > next point: can we avoid somehow with isar that this package is=20 > > > showing up in some apt repo (outside isar build system)? =20 > > > > All packages isar builds for an image show up in a repo called=20 > > "isar-apt" that is strictly internal.=20 > > > > If you choose to make use of the rebuild cache that will be another=20 > > repo - "base-apt". "base-apt" can be published and used for > > consecutive (re-)builds.=20 > > > > Isar does not publish anything on its own, nothing to be afraid of.=20 > > =20 >=20 > ok my misunderstanding, because "isar-apt" resides in the deploy=20 > subdirectory, I was assuming it may get published at some point=20 > (openembedded/poky had also an ipk subdirectory in deploy which could > serve as an external ipk repo). Well you can still publish it and "bootstrap" a debian out of it, together with base-apt. Let us just say nothing is ever published without you knowing it. Some people abuse Isar as a build system for debian packages only, they never even generate an image and they might copy "isar-apt" around and expect it to be in deploy. I think that is not "abuse" but in fact a really cool feature that still needs more users and documentation ;). > means this "base-apt" gets only generated when I was using "-c=20 > cache_base_repo"? about this directory I am not afraid, it contains > no self-built packages. That changed between master and next. It used to be an explicit step. Now this happens along-side and serves as a download-cache for everything debian fetches. =20 > kernel-headers-cip resides in "isar-apt", so I was more worried about > this apt repo. This contains every debian package we build in isar. The other one is a partial mirror of upstream. Henning=20