From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id E18C63858D1E for ; Wed, 1 Nov 2023 15:00:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E18C63858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E18C63858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=45.83.234.184 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698850814; cv=none; b=HAqPHCpvC7xZZk6Ehp7y3sBqVq18dYKc+cp2FmnN0OjoXA6cyFtF7hvTshAEf3AqdnBh5fZfl/JS9IuJmWuGBA4xdQ5C7FSDZ/W43ZurWmVvL5FZygDM67xGGNE4krtd80KUe20ehf3pzvPEChfrnZpvRDUpoovPDlHjEFUGAhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698850814; c=relaxed/simple; bh=3h/WZEgv3EMAXakraLfs8bABCElDsI9nrH0lNru4o6Y=; h=Message-ID:Subject:From:To:Date:MIME-Version; b=oxDdDfBchWbRG51XVZWPBLCGqxzSfkDwJDyr8LWSWLmWLgVoQufZXn3WD3l5P7QpGIz64APRrmVdgnJ4Mwx/kBzOxeCLZAk9RSzECwXIoT5YKOhdAN2JCUAil/Kek18BjTJTkeggin4U+f4hddQOQWhDOp56ujZ+qOj0Ym3vq3g= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id D0596302FDC3; Wed, 1 Nov 2023 15:59:57 +0100 (CET) Received: by r6.localdomain (Postfix, from userid 1000) id 18EDF34041E; Wed, 1 Nov 2023 15:59:57 +0100 (CET) Message-ID: Subject: Re: [PATCH] PR28204, debuginfod IMA From: Mark Wielaard To: "Frank Ch. Eigler" Cc: elfutils-devel@sourceware.org Date: Wed, 01 Nov 2023 15:59:57 +0100 In-Reply-To: <20231031154637.GA25062@redhat.com> References: <20231023193347.GB2863@gnu.wildebeest.org> <20231024132743.GC9683@redhat.com> <20231024210345.GE2863@gnu.wildebeest.org> <20231027191555.GD22548@redhat.com> <2148d29762c2046d5d7ce88df51ef91eb2113046.camel@klomp.org> <20231031154637.GA25062@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 (3.48.4-1.fc38) MIME-Version: 1.0 X-Spam-Status: No, score=-3026.8 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Frank, On Tue, 2023-10-31 at 11:46 -0400, Frank Ch. Eigler wrote: > > My point is really that posting with git format-patch or send-email > > makes it possible for someone to simply use git am, b4 or git pw to try > > out a patch. If the patch doesn't apply then that will be the first > > review issue. >=20 > I see what you mean, but maybe that puts the cart ahead of the horse. > What's desirable is easy access to a runnable version of the patch, > not the choice of command line tooling to do that. A published git > branch containing the same patch is even simpler than using git > am/b4/pw. git is the most convenient transport protocol for patches. Since we are discussing/reviewing patches on the mailinglist I think it makes sense posting them in a form that makes them easy to apply. That can be addition to some other way to also publish them. > > I think my issue is really that it is unclear what "reassurances" we > > are making. What is the threat-model? Permissive says to me that > > although checks are done, they don't block receiving files. [...] >=20 > In the current version of the users/fche/try-bz28204 branch, this > has been renamed "optimistic", and the man page blurb now says: >=20 > \fIima:optimistic\fP Every downloaded file with a known-invalid > signature is rejected, protecting against some types of corruption. I like this wording more. But maybe it would be helpful to split the patch into one that implements ima:enforcing and another that adds the ima:optimistic idea. That way we can more easily get the code in that we seem to agree on. And it makes it more clear what extra code is needed for the other policies. > > > They already make the decision whom they download debuginfo from. > > > That's literally what setting $DEBUGINFOD_URLS is. The scenario > > > you're describing would be trusting a server enough to supply content= , > > > trusting our code to fetch & check that content, but not trusting us > > > to redistribute public certificates for the servers. > >=20 > > The user shouldn't trust a middle-person. Unless we are signing those > > files we shouldn't distribute the certificates are being trustable > > imho. >=20 > We sign our elfutils releases, and packagers often sign their builds > of our releases, which users can verify. Right, but those are files we write and distribute. These are certificates that other use to sign files they distribute. > > So you propose we setup a curating process to decide which certificates > > to include?=20 >=20 > Sure. We already curate a set of debuginfod servers. You mean the list of servers that https://debuginfod.elfutils.org/ federates? I don't mind that server also maintaining a list of ima certs for those servers. But make sure the distros actually want someone else to redistribute their certificates. I can imagine distros wanting people to get their certificates from them directly. I don't think we should redistribute them as part of the main elfutils package though. >=20 > > > > [...] > > > > > Not sure, but this is how libimaevm.c similar code does it. I as= sume > > > > > the first byte of the signature is something else. > > > > > (https://git.code.sf.net/p/linux-ima/ima-evm-utils) > > > >=20 > > > > ewww. Does this pass ubsan (--enable-sanitize-undefined)? =20 > > >=20 > > > Haven't tried but it passes valgrind. > >=20 > > valgrind doesn't check for undefined behavior or type alignment > > requirements. >=20 > An elfutils build with --enable-sanitize-undefined had no complaints. Good. I still don't like the code, but at least it seems the compiler sees it as something that should work. > > One other issue I noticed is that it seems to be distributed under > > GPLv2-only. Which seems to mean that anything based on it should also > > be distributed under GPLv2-only, which would include libdebuginfod. Is > > there code we can rely on that is GPLv2+ and LGPLv3+ compatible? >=20 > Ugh. I don't know of an alternative. There isn't an equivalent > command line wrapping of the library either (with respect to > certificate searching) that we could fork out to. (OTOH, GPLv2 is > compatible with GPLv2+.) But GPLv2-only is not compatible with GPLv3 which is used by e.g. gdb. This is a bit of a pickle :{ > > > openssl's initialization is fine & thread-safe in practice, despite > > > the documentation's warnings. > >=20 > > OK. But even if it is thread-safe, you also need to make sure it inits > > the same. [...] >=20 > Interesting issue. One openssl initialization call is deep inside > libcurl, another one in libimaevm's solib ctor. Neither is > parametrized such that we could influence them. However, things are > working(tm). Thanks for checking. Cheers, Mark