From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7023151278367703040 X-Received: by 2002:a05:6512:3a85:: with SMTP id q5mr2276471lfu.250.1635399887137; Wed, 27 Oct 2021 22:44:47 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:1314:: with SMTP id x20ls1354954lfu.1.gmail; Wed, 27 Oct 2021 22:44:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNa087KLII1Qa9si+GLb2b8aavRjilK9GbptGbd0QEh5uIX+MMZVDDujvYAmIErp42GLyJ X-Received: by 2002:a05:6512:3054:: with SMTP id b20mr2103502lfb.509.1635399885934; Wed, 27 Oct 2021 22:44:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635399885; cv=none; d=google.com; s=arc-20160816; b=CKBIOufl+cCOUKS/DxydAxQ6PPMaKzXrSMznPsaopGWjlIvNnqH7SJEfvgZnDvj5nB crAd0XmC2LlO+nHgfh3Bp9xLUnEHgiODpTHOWMdngcFj7hinFksbuUBmhN652D2JiSaC ISliluumsY6g2Am1Fs6ePhyNvdbOkTWRlePsk57V/nxFzCAp63uZ9aVvuFJS2VdPa38k cTC8cveTwchxLDvV0H3RSjlOEBqcU4N7f09EO/jtYTcGWIheO2WjfAN3UG57bbg/OoCu hRlG46RnoVF46QLIMTrwVqqreaZXLRgVmqHzSfxROrmjQVdCDZCpeZr5WfGOWdmgXqAc hB5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=Sqd+f2zktc+bsqht06DPYsjUXvc+v2Qot4alxXlOG1w=; b=ZG68/WXioeCYOBpBVynB2aaQI+iJDDWCYpb/dDZ6Mr8flw+QXomK25rwy9rH6qAkYg ep/Lqy2wM0ng+Kd6WwPHx16J6wTic7O9kFkBWpi3VFqrH8+HnjMYc+TX1wE6UdVuH4m0 3qjsSUyVQy/QadYyIsBe3sqGfM8r07Tlaltq6teBXjXFuoRSkzvNbLQ561KmYIhHQQd2 BXnvlZB342dsZlbs8wpeVxlOnMyNa99LbMcU9H0sN42koaPjRpv6t5EMQHAAAyVHMooe 0+oD+tqFbAxp0ZTGDro0quQIdXt8s+LzgA6xPxbCKlKPRJE5Arv0bXXX7e6fR0Kl3RAG GZFg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@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 v2si3866lfo.2.2021.10.27.22.44.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Oct 2021 22:44:45 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@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 jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 19S5ii0E014061 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 28 Oct 2021 07:44:44 +0200 Received: from [167.87.0.189] ([167.87.0.189]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 19S5ih0l026290; Thu, 28 Oct 2021 07:44:44 +0200 Subject: Re: isar-bootstrap To: Henning Schild , ydirson@free.fr Cc: Anton Mikanovich , isar-users@googlegroups.com References: <20211026214408.22030b2f@md1za8fc.ad001.siemens.net> <849250711.1347880253.1635281333166.JavaMail.root@zimbra39-e7> <20211026231545.74e85f5d@md1za8fc.ad001.siemens.net> From: Jan Kiszka Message-ID: <0331e314-bdf6-915a-46af-3351bcd506f2@siemens.com> Date: Thu, 28 Oct 2021 07:44:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <20211026231545.74e85f5d@md1za8fc.ad001.siemens.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: etqH7r2Mftik On 26.10.21 23:15, Henning Schild wrote: > Am Tue, 26 Oct 2021 22:48:53 +0200 (CEST) > schrieb ydirson@free.fr: > >>> For the download Isar goes the pragmatic way and lets debian fetch >>> what >>> it wants. With a few exceptions ... i.e. there is only one "global >>> apt-get update" so you have to hope that you can apt-get install >>> what that initial run created your external database for. In >>> practice that does not fail too ofter ... or you have to clean >>> build again. >>> >>> If you really need to pin debian down to what it fetches, because >>> for some reason (like repro build) you need your own mirror. In >>> fact Isar spits out a partial debian mirror after an "online" build >>> (base-apt). That can be used for consecutive offline builds, or as >>> a base for consecutive "online" builds with custom >>> DISTRO_APT_SOURCES. >>> >>> While snapshots.debian.org can be used as DISTRO_APT_SOURCES mirror >>> in >>> theory ... in practice it has rate-limiting in place. So you might >>> succeed in a manual build that you retry over and over (or a small >>> image), but in CI without caching ... you will never get a big image >>> to >>> build. That rate-limiting issue will need to be discussed with >>> snapshots, we are not the first ones to have issues with it. >>> But i personally would tell people to simply not freeze if they can, >>> and the ones that need to freeze i would in fact tell to get a full >>> debian mirror of their own, instead of a partial one produced by >>> isars >>> base-apt. >>> As an OSS project you might see less of a need of freezing, tracking >>> in >>> fact is a security feature ... and debian will not do much more than >>> security on their stable distros. >> >> This is more of a concern for reproducibility of the build process >> at package level. Probably this was not published very widely, but >> there has been work on Debian package reproducibility in the context >> of Qubes already, including a solution to the snapshots.d.o problem: >> >> https://forum.qubes-os.org/t/reproducible-builds-for-debian-a-big-step-forward/6800 > > Cool stuff! I will give that service a try and look into where the tool > debrebuild comes into play. A tool that might in itself add some value. > > But to me it all seems like a workaround of the rate-limiting on > snapshots. A problem that can maybe be solved with funding, in case it > is a cost-problem. In Siemens people end up with their own > implementations of snapshots, which in sum likely costs more than > funding the real one for public non-limited use (together with other > stakeholders). > Still getting funding right and stable might be harder than any costly > workaround downstream. > I think i also heard trust arguments against snapshots, but those might > just be pointless. Even if it is not-Debian (is it?) there will be gpg > in place, but then you still need to trust that you get what you asked > for because if a snapshot holds back a security update gpg would not be > able to tell. > > But yes, good stuff! I bet that can be used in Isar somehow, but maybe > only in your layers. You might not want the load from others on your > infra. And the amd64 limitation is kind of severe. We have arm64 > becoming more and more relevant and even riscv working for early > prototypes. And i686 and arm32 floating around in places for some time > to be maintained. Missing non-amd64 support is exactly the reason why we are not yet broadly using that alternative snapshot - too many of our use cases are armhf or arm64 (extremely few are still i386). Compared to that, [1] is then only a minor issue. Reproducibility is a strategic topic for us, just not yet one with highest urgency. However, people start to look into this in Isar context already (see e.g. [2]). Jan [1] https://github.com/fepitre/debian-snapshot/issues/2 [2] https://groups.google.com/g/isar-users/c/GXYNmEpn-ns/m/tb7MKx3FAAAJ -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux