Re: Adding functionality to a port

From: Rob LA LAU <freebsd_at_ohreally.nl>
Date: Sun, 14 Nov 2021 20:20:15 UTC
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/