Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Nov 2021 20:43:15 +0100
From:      Kurt Jaeger <pi@freebsd.org>
To:        Rob LA LAU <freebsd@ohreally.nl>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: Adding functionality to a port
Message-ID:  <YZFm03wMTIwmV415@home.opsec.eu>
In-Reply-To: <9f00f43c-0fc6-bcda-1f71-fdaddcad3d0c@ohreally.nl>
References:  <4ca51765-b556-3f12-5809-5aadbf6dccca@ohreally.nl> <YZEskkPi2%2BcX9hrZ@home.opsec.eu> <480b44f5-0674-e645-8413-a1a368cfc393@ohreally.nl> <YZExLlXP3uEjrvyF@fc.opsec.eu> <fb5e514d-1458-9b49-1882-b64d5386cdfa@madpilot.net> <YZFGCoblQOHPnPWe@fc.opsec.eu> <e07b5a48-3465-c92b-ee4b-f2fc91e0202f@madpilot.net> <YZFXby/ktthO9Khx@fc.opsec.eu> <9f00f43c-0fc6-bcda-1f71-fdaddcad3d0c@ohreally.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
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 ?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YZFm03wMTIwmV415>