From nobody Sun Nov 14 20:20: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 687D4184E224 for ; Sun, 14 Nov 2021 20:20:00 +0000 (UTC) (envelope-from freebsd@ohreally.nl) Received: from rambler.ohreally.nl (rambler.ohreally.nl [51.15.8.63]) (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 4HskFr1xZ5z3kHg; Sun, 14 Nov 2021 20:20:00 +0000 (UTC) (envelope-from freebsd@ohreally.nl) Received: from authenticated-user by rambler.ohreally.nl (Postfix) with ESMTPSA id 3BA3C1D77A90; Sun, 14 Nov 2021 21:19:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ohreally.nl; s=dkim; t=1636921199; r=y; bh=NVjGwUoNrCe+SnOvfrRSyBr7jsdLiSFPJOHwyeuw2JM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=z0GPYIN4ArUpxTXumhGlVjR8vw4b5tvyU8pxqP+EjlEXUK5bArUZcngmxCtMWkz1i x6vL+6ma9MGhYAkWBpc3xRn0hB9A4wXHVvfuaqydEZ60YbKte+RbEdznYvQLFE6Izj Zpt39iPozJILBZwR5b3W9YUCWdIVOM5zo19MmlH8= Message-ID: Date: Sun, 14 Nov 2021 21:20:15 +0100 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 Subject: Re: Adding functionality to a port Content-Language: en-US To: Kurt Jaeger Cc: freebsd-ports@freebsd.org References: <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <9f00f43c-0fc6-bcda-1f71-fdaddcad3d0c@ohreally.nl> From: Rob LA LAU In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.104.0 at rambler.ohreally.nl X-Virus-Status: Clean X-Rspamd-Queue-Id: 4HskFr1xZ5z3kHg 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, >> "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... But since those additional ports would also be closer to their upstream, each individual port would need less patches and be easier to maintain. So even if the ports tree would be larger, it would also be cleaner. > In general, patches and modifications are not submitted/committed > with malicious intent. I'm sure that that is true, But nevertheless, several colleagues have had their repositories compromised, so if this hasn't happened to FreeBSD yet, and FreeBSD doesn't have any measures put in place, it is probably just a matter of time. [1][2][3][4][...] > 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 ? No, it should assume the best. And be prepared for the worst. Why should you only marry with a prenup? Because it's not in the way if things go well, and it's good to have organized everything beforehand if things do not go well. If the porters really care for FreeBSD, they will understand and agree that it must be protected against people who care a bit less. If their ego cannot take some simple rules that will undoubtedly reduce the risk of the ports tree getting compromised, then maybe they don't care as much for FreeBSD as they say. IMHO, of course. Rob [1] https://www.securityweek.com/arch-linux-aur-repository-compromised [2] https://www.securityweek.com/hackers-plant-malicious-code-gentoo-linux-github-page [3] https://blog.gridinsoft.com/more-than-700-malicious-libraries-detected-in-rubygems-repository/ [4] https://www.bleepingcomputer.com/news/security/malicious-pypi-packages-hijack-dev-devices-to-mine-cryptocurrency/ -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/