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.

Is there any kind of minimal build of gnupg that could be useful without
the gazillion dependencies ?

Reply via email to