Adding functionality to a port
Hello list, I'm wondering what the rules/guidelines are for adding functionality to a port, that is not in the upstream package. I can't find anything about this in the porters' documentation. Background: I'm not a porter myself (planning to be one, but that's irrelevant for my current question). I ran into a buggy `periodic' script. And when looking for the port maintainer to report the bug, I found that this script is not part of the upstream package, but was added to the port by the port maintainer. So I'm wondering now whether I should report the bug in the `periodic' script, or ask the maintainer to remove the script from the port (and maybe submit it as a separate port). And in more general it would be interesting to know when changes made to a port are considered too drastic, and when port maintainers should be asked to join the upstream development team instead of (or in addition to) maintaining the port. Thanks for any and all replies. Cheers, Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
Hi Kurt, On 14/11/2021 16:34, Kurt Jaeger wrote: You can ask the maintainer if he wants to join upstream, but if there's no interest, there's no need to pressure one into upstream 8-) Don't worry: I don't want to pressure anyone into doing anything. :) But I would like to know how much functionality a port maintainer can add to a package before it is considered too much. At some point the port will no longer represent the upstream package, and I'd really like to know where this limit is. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
Thanks Ronald. But I'm not asking how or where to report bugs. Allow me to rephrase my question. If and when I am a FreeBSD port maintainer, can I just add any scripts or other files to the port I maintain if I think they may be practical, even if those files are not part of the upstream project? Thanks, Rob On 14/11/2021 16:40, Ronald Klop via freebsd-ports wrote: On Sun, 14 Nov 2021 16:26:23 +0100, Rob LA LAU wrote: Hello list, I'm wondering what the rules/guidelines are for adding functionality to a port, that is not in the upstream package. I can't find anything about this in the porters' documentation. Background: I'm not a porter myself (planning to be one, but that's irrelevant for my current question). I ran into a buggy `periodic' script. And when looking for the port maintainer to report the bug, I found that this script is not part of the upstream package, but was added to the port by the port maintainer. So I'm wondering now whether I should report the bug in the `periodic' script, or ask the maintainer to remove the script from the port (and maybe submit it as a separate port). And in more general it would be interesting to know when changes made to a port are considered too drastic, and when port maintainers should be asked to join the upstream development team instead of (or in addition to) maintaining the port. Thanks for any and all replies. Cheers, Rob You can file a bug report on https://bugs.freebsd.org/ . If you use a summary like 'www/firefox: Unable to use microphone with ALSA backend' it is automatically assigned to the maintainer of the port. So 'portname>: short description of bug'. You can also upload a patch if you have it. If a bug report is not possible you can also just mail the maintainer and see what the reaction is. Regards, Ronald. -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
Hi, On 14/11/2021 16:54, Kurt Jaeger wrote: Maybe it makes it easier to understand if you tell us the port in question ? It won't actually, because I don't want to focus on this 1 buggy script I found. My question is not about a single bug in a single script. It's about FreeBSD policy, trust, security and reliability. As a port maintainer, can I just modify the functionality of the ports I maintain without any limits? And as a software developer, can I be sure that the package that is installed on FreeBSD systems, and that carries my name and URL, is actually still the package that I developed, with the functionality I intended? And as a sysadmin or user, can I be sure that the port I installed actually does what is advertised on the upstream website? I honestly think that these are very important questions... The internet is no longer this friendly place it was 30 years ago. People with malicious intent have infiltrated software repositories before, and they will keep doing so. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
Hi again, 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. 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." Having rules for these situations means that tools can be created to verify and enforce those rules. Not having these rules is an invitation to people with malicious intent to integrate backdoors, keyloggers, and what not into the ports. IMHO. Rob [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_all_patches_should_have_an_upstream_bug_link_or_comment -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
And hi again, On 14/11/2021 19:42, Guido Falsi wrote: > IN fact I would very astonished if some port (say firefox for example) started behaving very differently than it does on other OSes for no good technical reason. True. But what if we're not talking about 'behaving very differently'. How about we patch a browser to send the user's passwords to a server we own, while - apart from that - the browser continues to work as expected? > OTOH a valid technical reason could be dropping some functionality depending on some API not available on FreeBSD, just to make an example from the top of my head. Dropping something because it is impossible to implement is different. Sometimes you don't have a choice. My initial question was about a script that was added by the port maintainer, which is not quite the same. Patching software to log keystrokes, or to open a backdoor is also different. Clearly you can't solve all these problems by creating some guidelines and rules. But I don't think that a serious software project can continue without rules. Just like we need passwords and keys. And preferably those rules would be very clear and simple, so that the compliance can be verified (largely) in an automated fashion. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/
Re: Adding functionality to a port
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/
Re: Adding functionality to a port
Hi, On 14/11/2021 20:49, Guido Falsi wrote: You talk about "adding a periodic script". That is not even a real modification to the upstream software IMHO. Just adding some glue code for FreeBSD. If the script does what it advertises, and has no malicious intent I see nothing wrong with it. If it is broken fixing it is the logical thing to do. Imagine a daemon, an rc script and a periodic script. And imagine that we decided to separate all 3 into separate ports. When fitting these ports into the ports tree, we would make the daemon depend on the rc script, because the daemon needs the rc script to start and stop (and starting and stopping could be considered core functionality). But we would make the periodic script depend on the daemon, because the daemon runs fine without the periodic script, but the periodic script is useless without the daemon. To me this would mean that the daemon and the rc script should be published together as a single port, making the rc script an acceptable FreeBSD-specific addition. (Which does not mean that the addition should not be reported to upstream; the goal should also be to have the rc script included in the upstream project, just like the systemd unit that is already included.) The periodic script, however, should be considered new functionality, and published in a separate port. And to contradict the above, one could now plead that external libraries that the daemon depends on should also be packaged together with the daemon, but the difference obviously is that no other package will ever depend on the daemon's rc script, while those libraries have been created to allow multiple applications to use them. And there will always be exceptions. Things are not always black and white, and they shouldn't be. And obviously, I'm the outsider here. I'm not trying to tell anyone what to do and how to do it. I'm just making sure that this subject has not been overlooked. Being a son of two lawyers, and having a lot of friends who are lawyers, and also clients who are law firms, my informed (by having had a lot of arguments with all these people about this very subject) opinion is that there is no such thing in the world as a "clear and simple" set of rules. Nobody is trying to write a legal document here. The goal is just to assure that the ports in the ports collection still function as intended by the upstream developers, preferably with no functionality removed, and definitely with no functionality added. Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/ https://github.com/ohreally/
Re: Adding functionality to a port
Hi, On 15/11/2021 10:21, Guido Falsi wrote: You look too worried by the "functionality added" part. Yes, I am worried. Of course I am. When I first asked my question the day before yesterday, the first responses were in the line of "port maintainers can do whatever they want", accompanied by emoticons with sunglasses. So that kind of makes me wonder how seriously FreeBSD takes itself, as an OS. I understand very well that a startup script or similar stuff can be added without any problem. But what worries me, is that apparently there are no limits or rules whatsoever. Even OpenBSD, if you want to keep it close to home, dictates that all patches, work-arounds and dependencies must be documented, and that all changes must be sent upstream to try and have them included in the original work. [1] (And when I say 'Even OpenBSD' I don't mean to say that OpenBSD is any less than FreeBSD, but just that it could be considered a small player, compared to FreeBSD or most other OSes.) I run real servers, so as a sysadmin I want to be able to rely on the fact that the software I install does exactly what is advertised in the upstream documentation, no more and no less. And that's not just from a point of view of security for just me. I run 2 Tor relays, so it's potentially the security of many more people (where 'security' could mean a way bigger risk than just losing some files). And yes, I am sure that Tor runs as advertised, because I verified that (as far as I could). But what if the port maintainer of some obscure library, that is installed through some bizarre chain of dependencies, managed to sneak in a backdoor that gives them root access to my server? Then the security of my Tor installation is no longer relevant, because an attacker can just gain root and compromise that installation. And please don't tell me that that would be illegal, because the amount of attempts I receive on my servers every day tells me that not everybody is as law abiding as you apparently are. Apart from that, triggered by this email conversation, I studied some open source licenses in the past days. And apart from the BSD licenses, MIT license and Mozilla Public License, most open source licenses require modifications to at least be well documented (GPLv2, article 2.a; GPLv3, article 5.a; Apache License, article 4.2; LGPLv2, article 2.b; CDDL-1.0, article 3.3). Which means that even the added startup scripts should carry a notice saying something like "This file is not part of the original distribution, but was added for FreeBSD - ". So if you want to talk about legal stuff: current practice may violate some licenses. I really understand that not everything can be cast in stone. And I understand that there must be some freedom for port maintainers. And I don't want to be a Karen about it either. I am even rather pro-anarchy. But not on the servers that keep my data and that of others secure. I'm just looking for some guarantees for me and my users. I understand that 100% guarantee is hard, if not impossible, but I would like it to be a bit more than "You just shouldn't do bad things.". But I understand that I'm alone in this: only 3 or 4 people have responded, and they all seemed to be very much against any rules for port maintainers. So I won't insist any more. Best, Rob [1] https://www.openbsd.org/faq/ports/guide.html -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/ https://github.com/ohreally/
Re: Adding functionality to a port
On 16/11/2021 17:59, Jose Quinteiro wrote: Openbsd packages come with the following caveat: > [...] Every operating system comes with this caveat; OpenBSD just says it out loud. No BSD, nor any Linux distro, has the resources to go through the source code of all ported software, to make sure it has no holes. This responsibility is left with the developers of the software in question. Which is one of the reasons why porters should make as little modifications as possible, and document the modifications they do make: so that it is clear where the developers' responsibilities end and the porters' responsibilities begin (and vice versa). Rob -- https://www.librobert.net/ https://www.ohreally.nl/category/nerd-stuff/ https://github.com/ohreally/
