On 21 December 2014 at 14:40, Björn Persson <Bjorn@rombobjörn.se> wrote:
> Stephen John Smoogen wrote: > >On 21 December 2014 at 09:28, Björn Persson <Bjorn@rombobjörn.se> > >wrote: > > > >> Mattia Verga wrote: > >> >The alternative could be a "open approach" from Firewalld, where an > >> >application, when it's executed, can inform firewalld that needs to > >> >open a port, firewalld asks the user if it should grant access to > >> >the application and then opens the port... but this needs to be > >> >implemented in the source of every application, it can eventually be > >> >sponsored to become a standard in the linux world. > >> > >> There is already a way for an application to inform the operating > >> system that it needs to open a port. It's called the Berkeley socket > >> API, and every program that communicates across a network already > >> uses it. Why don't you guys patch GlibC's implementations of bind > >> and connect to notify FirewallD and get it automatically enabled in > >> every program, instead of requiring every communicating program to > >> call a second API in addition to the Berkeley socket API? > > > >I am expecting because the patch would break other things > > What things would it break that wouldn't be broken if every program had > to call FirewallD on its own? > > >and would be > >something that upstream would not want accept to glibc. With Fedora not > >wanting to put in patches not accepted by upstream it would be less > >accepted that firewalld is. > > So you think that countless other upstreams would feel compelled to > accept the patches to always open ports twice, because they want their > software to work on Fedora, but GlibC is important enough to be able to > refuse without risk of being dropped from Fedora? Or maybe that GlibC > can refuse because it's a library and can push the problem up to the > programs? > > Uhm no. You seem to be wanting a fight over something, and I have no mood to engage. I hope you have a more pleasant holidays than what your tone indicates you are currently having. > -- > Björn Persson > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- Stephen J Smoogen.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
