On Thu, Jul 06 2023, Stuart Henderson <s...@spacehopper.org> wrote: > On 2023/07/05 21:21, Jeremie Courreges-Anglas wrote: >> On Wed, Jul 05 2023, Alexander Bluhm <alexander.bl...@gmx.net> wrote: >> > On Wed, Jul 05, 2023 at 05:35:01PM +0200, Jeremie Courreges-Anglas wrote: >> >> On Tue, Jul 04 2023, Alexander Bluhm <alexander.bl...@gmx.net> wrote: >> >> > Hi, >> >> > >> >> > ok to import splicebench-1.02 ? >> >> >> >> At first I got puzzled by SUPDISTFILES but gofor it if you find it useful. >> > >> > If upstream provides a gpg signature, I download it and check it. >> > Although it is not perfect to prevent backdoors, I would feel very >> > bad, if I would commit a tampered port that could be detected by a >> > signature. >> > >> > Downloading the detached signature as SUPDISTFILES makes it easy >> > to verify manually. >> > >> > Any better idea to prevent supply chain attacks? >> >> I'm not objecting to the rationale, I also check signatures whenever >> I can. This reminds me of a proposal from Stuart which I liked a lot >> but I haven't pushed for... until now: >> >> https://marc.info/?l=openbsd-ports&m=157687699320320&w=2 > > I lost interest when it turned into a load mkre complication and a new > tool to verify pgp signatures that would only run on certain archs > and reverted to my previous method, "stick a shell script in the port > directory that will download and check the signature when run by hand".
Your original approach looked good to me. Was the additional complexity warranted by security or usability concerns? You mention a "new tool", I would prefer if we kept using security/gnupg instead of some go/rust program, precisely for portability reasons. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
