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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
