----- Original Message ----- > if your discussions leaded to the decisions also used the quoting style > like in that thread only contain "myself said" i guess what went wrong > in the first place > > i am still unsure if that's > > * intentional to mask communication > * just a bad usage of your mail-client > > in any case it's not the default behavior if someobdy press "reply" It's the default behaviour in the Zimbra web interface, which I use because I don't like getting trolled at week-ends. > Am 08.12.2014 um 16:23 schrieb Bastien Nocera: > > > > > > ----- Original Message ----- > >> On 12/08/2014 03:45 PM, Bastien Nocera wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> On 12/08/2014 03:12 PM, Bastien Nocera wrote: > >>>>> > >>>>> > >>>>> ----- Original Message ----- > >>>>>> On 12/08/2014 12:51 PM, Bastien Nocera wrote: > >>>>> <snip> > >>>>>> This is wrong and you know about that - the firewalld folks have been > >>>>>> urged to use this zone for the Workstation product - it was a > >>>>>> Workstation team decision. > >>>>> > >>>>> What?! We discussed it, and it was deemed acceptable by you, and mitr. > >>>>> We went back and forth on this, and you agreed that it was a good > >>>>> cost/benefit decision. > >>>>> > >>>> We could choose between removing firewalld and accepting this zone ... > >>> > >>> Which you could have refused if you felt that it was an unacceptable > >>> compromise. > >>> Which you didn't do. Are you still going to argue that this wasn't > >>> _vouched_ for > >>> by you and the other firewall stakeholders? > >>> > >> > >> Yes, exactly in the same way as I could say "no" to the removal of all > >> firewall UI tools ... > > > > It's not in the default installation because it's not needed. It wouldn't > > have > > been needed either for any of the other possible options. > > > > Also, the "we had a choice between removing firewalld or accepting this > > zone" is > > completely untrue. Fesco had refused the removal of the firewall in the > > past, > > and I don't think that it would have been accepted this time either. So > > modifying > > the default firewall, or modifying the firewall interaction was necessary. > > > > Given that the firewall doesn't protect any data in the session whether > > with the > > workstation zone, or with a fully blocking one (apart from one that > > disallows any > > networking, obviously), then I don't see what the problem is here. > > > > The firewall in the session didn't improve security, it slightly improved > > privacy though, > > which is something that we've looked into, and implemented a new sharing > > framework > > to avoid sharing services being launched in networks where it wasn't > > intended. We also > > changed the default avahi configuration to not leak information about the > > machine. > > > > The net result is that the only services running on a default Workstation > > installation will > > be as a consequence of users turning them on. No information about the user > > is leaked unless > > they choose to share it by sharing data. > > > > Having a good default also means that we avoid the turning off of the > > firewall as a big > > hammer, just as we protect users better by enabling an SELinux with > > configurations that work > > by default, and why it's a problem when SELinux gets in the way of user > > wanting things to work. > > > > See also: > > http://www.superlectures.com/guadec2013/more-secure-with-less-security > > Consider this my closing note on this subject. > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
