Re: Adding functionality to a port
- Reply: Rob LA LAU : "Re: Adding functionality to a port"
- In reply to: Rob LA LAU : "Re: Adding functionality to a port"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 ?