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?

--
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