From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Jan 2025 17:04:52 +0100 Received: from metis.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::104]) by lore.white.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tXjPQ-0014zk-1N for lore@lore.pengutronix.de; Tue, 14 Jan 2025 17:04:52 +0100 Received: from localhost ([127.0.0.1] helo=metis.whiteo.stw.pengutronix.de) by metis.whiteo.stw.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1tXjPP-0005mS-Sc; Tue, 14 Jan 2025 17:04:51 +0100 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1tXjPK-0005mC-2F; Tue, 14 Jan 2025 17:04:46 +0100 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-2efb17478adso9427361a91.1; Tue, 14 Jan 2025 08:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736870684; x=1737475484; darn=pengutronix.de; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1chZrL6hsblobpwnfxeI4foZZQVyFHPjZdtnVc7XqgE=; b=h19/YkKheMq9itUOkvHsOIUZlxGQ4WDRyX/LfbiW9VxQvP2b/K7TvGf33j84WfgCaN EMYcQgdq9NqEA4UrgagCfMC5SrgpIMHVf/jpl4+D8O6QD4YHTwCx/iX8hJyaZSHIzoiW otX5BhgaVCyn7JdLFg1Qgm7RSmlwr7+TKMCMC0W1Qm6XlDWOgc+FkcHH+ycJy/aJ17SF NtVXRkxAqxTGK4uOcE1orXfZS4aDclFn+CvYi5LzlizRbwYfWaUCmw1+S034/wxyif3D X8OvLF0Sps5VYLJhaw4rIwCU9wX4T2M0CaEOnFkPdF9bCmAXnF5LgqLxfZO6EHKEqEFz 9T/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736870684; x=1737475484; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1chZrL6hsblobpwnfxeI4foZZQVyFHPjZdtnVc7XqgE=; b=tuw1YgfCHj9+5PtbusY1inRctyC88BzNUgCGIrBv5o4s8trd2DlyjFvuplBOlmAL+J uMcz8RutiHnAN3WKJwCrRFX8rxDMB0lRMoP8wzqYGUTZcOTjlRKh3fgIY2MDIhZH5UDq ehEhW6vjK5HL3GRKgGzRiPum0e2t1iAo+s//+F5weMp+TPJCkNIcH+/VMWphQkE02C3u maGrOuIEOmTk0ztjeT3FF6PibicnPnGWoil4ocvWNhSb0S8J/5BXr+qEBEI3O3jqV5l0 Of4iLZiDuHVtPMsRP9oblRZZdoKCzDxUYQ3nXLNGz+gVwxg2HwCi2WI1hHU5gDw4/Rh5 KXhQ== X-Gm-Message-State: AOJu0Yx8F011w5qwp+HCV2SJDTsLwkpDz75FDPDALbf+m12N/mEhlfme HHp9W3ZtPlQ+el1Y8o0SqxrXfgE07ALZf0JUffMjMAL5A9h1fGMQy96SwFwW0RxqxxZWfsYpgUb 6Vpvi85wdpOzr6Eu/HKdXZlYomtOiLQ== X-Gm-Gg: ASbGncuRpuauzgXANsA3uM7cDyy3X4cENEioO3dLVzbPTPox/LKguQQmXj5HRAwzZv6 PwjfqwObnoCqtTcFg7Qw/5VEwG5W0T3zzn2Wa4uM= X-Google-Smtp-Source: AGHT+IHtkpsM4k/gKI76DvPcp1jDfWXxP6di/pknDknD9zqaKNlw/kz6FLcDTA1ifm/WmYa9mMSdUconlhgut3ic+Uc= X-Received: by 2002:a17:90b:2e8b:b0:2ee:ee77:2263 with SMTP id 98e67ed59e1d1-2f548f0894dmr38235727a91.7.1736870684112; Tue, 14 Jan 2025 08:04:44 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 14 Jan 2025 11:04:32 -0500 X-Gm-Features: AbW1kvaheSboLkWaMGHs4rZ0qML03RmgxiHIX3c98OM7aJ2So5g-2KLi6j3AY8o Message-ID: To: =?UTF-8?Q?Jan_L=C3=BCbbe?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on metis.whiteo.stw.pengutronix.de X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Subject: Re: [RAUC] Is it possible to change the [system]compatible= string after it has already been set/flashed? X-BeenThere: rauc@pengutronix.de X-Mailman-Version: 2.1.29 Precedence: list List-Id: RAUC Project - Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Brian Hutchinson via RAUC Reply-To: Brian Hutchinson Cc: rauc@pengutronix.de Sender: "RAUC" X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: rauc-bounces@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false Hey Jan, On Tue, Jan 14, 2025 at 10:52=E2=80=AFAM Jan L=C3=BCbbe wrote: > > On Tue, 2025-01-14 at 10:38 -0500, Brian Hutchinson via RAUC wrote: > > On Mon, Dec 9, 2024 at 3:43=E2=80=AFAM Jan L=C3=BCbbe wrote: > > > > > > Hi again, > > > > > > On Thu, 2024-12-05 at 22:38 -0500, Brian Hutchinson via RAUC wrote: > > > > This almost feels like the intermediate update that's necessary wit= h > > > > changing rauc versions ... > > > > > > Enrico pointed me to this part. > > > > > > Updating RAUC versions normally does *not* require an intermediate > > > update. An intermediate update is only needed if you explicitly creat= e > > > bundles which use new features: > > > https://rauc.readthedocs.io/en/latest/basic.html#forward-and-backward= -compatibility > > > > Thanks! > > > > I should probably start another thread, but now I'm running into a > > chicken & egg problem. > > > > I need to add downgrade protection due to newer hardware > > Just to clarify: You want to prevent installation of an old bundle on the= new > hardware, as the old software would not work on the new hardware? Yes, but not based on version alone, version and some hardware checks. > > > and I > > discovered pre-install handler doesn't have access to bundle version > > (RAUC_MF_VERSION), only a hook has that environment variable. Well, > > if I create a hook that can compare bundle version to current version > > to do some hardware checks ... that hook won't be in older bundles, so > > wondering how pre-install handler (which lives in the current version > > file system) can figure out the bundle version attempting to be > > installed if it can't see RAUC_MF_VERSION to implement downgrade > > protection if that makes any sense. > > Take a look at the "min-bundle-version" option in the system.conf: > https://rauc.readthedocs.io/en/latest/reference.html#system-section > > You'd set that in the factory image of your new hardware. That way, old b= undles > cannot be installed. Yeah, looked at that and won't help me. If pre-install handler can get to the bundle version attempting to be installed I'd be ok. Currently looking at RAUC_META_. Looks like pre-install hook can access the bundle manifest. So I might allow a downgrade if the hardware is compatible, but if the hardware is not compatible then I have to deny the downgrade. So it's got to be pre-install handler since that lives in current version rootfs ... but I need to figure out how to access the version of bundle attempting to be installed. That's where I'm stuck. Regards, Brian