From nobody Sun Nov 14 19:43:15 2021 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 60529183A5BA for ; Sun, 14 Nov 2021 19:43:19 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HsjRW2QZzz3H0c for ; Sun, 14 Nov 2021 19:43:19 +0000 (UTC) (envelope-from pi@freebsd.org) Received: from pi by home.opsec.eu with local (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mmLPH-000HiE-CU; Sun, 14 Nov 2021 20:43:15 +0100 Date: Sun, 14 Nov 2021 20:43:15 +0100 From: Kurt Jaeger To: Rob LA LAU Cc: freebsd-ports@freebsd.org Subject: Re: Adding functionality to a port Message-ID: References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <9f00f43c-0fc6-bcda-1f71-fdaddcad3d0c@ohreally.nl> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f00f43c-0fc6-bcda-1f71-fdaddcad3d0c@ohreally.nl> X-Rspamd-Queue-Id: 4HsjRW2QZzz3H0c X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Hi! > On 14/11/2021 19:37, Kurt Jaeger wrote: > > I agree. The problem is that this is very difficult to codify > > into some policy. > > I've done some digging. And actually, Fedora only needs a few words: > > "All patches should have an upstream bug link or comment" [1] > > This assures that packages stay close to their upstream projects. As FreeBSD's not Linux, we often have the problem that bugs reported upstream are not accepted, discarded or ignored 8-} But in general, this sounds like a useful rule, if we do not enforce it too rigidly. > Another rule could be > > "Patches should only be applied to make the software run as intended by > its developer. All additional functionality should be integrated upstream > first or, if that's not possible or desirable, should be developed as a > separate project which can then be ported alongside the first port." This would lead to a lot of additional ports, because of above... > Not having these rules is an invitation to people with malicious intent > to integrate backdoors, keyloggers, and what not into the ports. IMHO. In general, patches and modifications are not submitted/committed with malicious intent. And, as far as I understand, open source project do not write rules to protect against the worst possible case/attacker, because that might slow other contributors. The workflow should include checks to protect. If checks against worst-cases can be automated, wonderful. But should the rules really assume the worst from its contributors ? -- pi@opsec.eu +49 171 3101372 Now what ?