Re: Adding functionality to a port

From: Kurt Jaeger <pi_at_freebsd.org>
Date: Sun, 14 Nov 2021 19:43:15 UTC
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 ?