On Fri, Jul 07, 2023 at 01:01:06PM +0100, Stuart Henderson wrote: > On 2023/07/07 11:17, Marc Espie wrote: > > On Thu, Jul 06, 2023 at 05:49:04PM +0200, Jeremie Courreges-Anglas wrote: > > > 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 > > > > > > > > Looking at sthen's patch. How verbose is gnu-gpg ? > > Specifically, is the "signature failed message" enough to identify > > which file failed. > > > > I'm not too sure about the BUILD_DEPENDS: gnupg has got a lot of > > dependencies. > > > > I see the distinct possibility of build loops if CHECK_PGPSIG was set > > indiscriminately in mk.conf. > > hmm - perhaps it would be better in a different make target (or not > handling verification from make at all; just provide a way to list/fetch > ignature files so they can be handled externally, say via a script that > uses "make show=SIGFILES"). > > I wasn't intending for this to be used indiscriminately - in particular > I didn't want to have this extend into key management, just use what > your normal user account has specifically added and trusted - so given > that, it's unlikely that it would even be able to verify files for > ports other than ones that you're particularly interested in.
My usecase would be that I can do 'make verify' when I update a port. The author's key is in my personal key ring, ~bluhm/.gnupg/pubring.gpg . Maybe it should be done automatically when I run 'make makesum'. My current workflow is that I add *.asc to SUPDISTFILES. During 'make makesum' I see that a signature is downloaded and I verify it manually. bluhm > > Is there any kind of minimal build of gnupg that could be useful without > > the gazillion dependencies ?
