From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id DC1DD3858D32 for ; Tue, 14 Nov 2023 16:45:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DC1DD3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DC1DD3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699980355; cv=none; b=iPb8sVyFrSkNYS7Ks18Xjam7yMR407S/eRzuruczY3xvn6FSf7Bw6bU39kvLH0tqJLQWcyhN2pXeHdgub32DjJiD2zI4vUTHmj7i12ub/VR3jMWPlf+T3mPZyNbrpy8urbvJEES5J1wbr26nHhvnFWFazFqijWfQgy9g25xSpFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699980355; c=relaxed/simple; bh=xwVt45+vU1cQBP4+4e9unzvVroSoK6IuryPPfB7g7Bo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=YwNDYUDPlHasSc6ZV+K6jwsIdb/7VFbCn39gvsEjYgUCZGsTXLlZodVkxyLZLkYjRiAd0Wxxs7jCWMQvAhtpjQau0rrSimSlwwMMAsjr4iuoT/njIwbV8Pt+43wIaP0sE1hQzZJpvDoa4wK3L5F3Gv5OZwdbP7M4Ylqu93ltIKI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699980353; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0fxrOXd+EM+nvb1pWrc/2XGKg4wp77yr39KFM/CvAWI=; b=MkftTmBTjD4VqxDmE42m26N1meTFATsNli+KEfReodqtn4y7xV2XqdFcQRgbWLbrrkvCk/ w3CokWEQ00XLjHkg6Ea/kJEdz1oLw2gE9fdPJ3aAsciPucJRGdrXi+UCt5UO3Ablp7Cccm ujto1j8rGvA7cwfTk+/089mywn6A1eE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-386-ydFJBA8SOGCg_eGtpC5dnQ-1; Tue, 14 Nov 2023 11:45:50 -0500 X-MC-Unique: ydFJBA8SOGCg_eGtpC5dnQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 08146811E7D; Tue, 14 Nov 2023 16:45:50 +0000 (UTC) Received: from redhat.com (unknown [10.22.8.8]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E8C6F1121306; Tue, 14 Nov 2023 16:45:49 +0000 (UTC) Received: from fche by redhat.com with local (Exim 4.94.2) (envelope-from ) id 1r2wXt-0003rj-0V; Tue, 14 Nov 2023 11:45:49 -0500 Date: Tue, 14 Nov 2023 11:45:48 -0500 From: "Frank Ch. Eigler" To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: [PATCH] PR28204, debuginfod IMA Message-ID: <20231114164548.GG32463@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> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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 - > > \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. I interpret this as a veto for the "optimistic" mode. Too bad, this is going to reduce usability and utility. What mode do you want by default then, "ignore" or "enforcing"? > > 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. They use unpublished private keys to sign files. Public certificates allow anyone to verify the signatures. > > > So you propose we setup a curating process to decide which certificates > > > to include? > > > > 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. I assume you mean to require users to manually download & install them somehow. > 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. Certificates are public keys. They are literally designed for wide distribution. They may be authenticated further by certificate chains, but there is little harm to even crafted certificates. They would not be usable to verify signatures, leaving the user no worse off than without the certs. > I don't think we should redistribute them as part of the main elfutils > package though. I interpret that as a veto. > > 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 :{ I interpret that as a veto. OK, will have to set time aside to rewrite this code. - FChE