"Workstation" Product defaults to wide-open firewall

Christopher ctubbsii-fedora at apache.org
Tue Dec 9 04:33:14 UTC 2014

On Mon, Dec 8, 2014 at 10:36 PM, Matthias Clasen <mclasen at redhat.com> wrote:

> On Tue, 2014-12-09 at 01:35 +0100, Kevin Kofler wrote:
> >
> > To me, it is obvious that the Workstation WG is in deliberate contempt of
> > FESCo's decision. That alone ought to lead to sanctions from FESCo. In
> > addition, FESCo's decision must be implemented properly by a security
> update
> > ASAP. A wide-open firewall is a security issue. We CANNOT leave it
> unfixed.
> Ah, the appeal to authority, lovely.
> I know it is hard, but maybe try to accept that there are different
> views of the world, and not everybody shares black-and-white one. The
> sky is not falling just because we are shipping a non-paranoid firewall
> configuration.
I think you're being overly dismissive of legitimate security concerns. The
whole purpose of a firewall is to lock down the system from unintentional
network traffic. The default installation of the "Workstation" product does
not perform this function. This isn't paranoia. It's the only function. The
"you had one job" meme comes to mind.

Also, if this is was a circumvention of a FESCo decision, that seems to me
to be a serious concern. It is an appeal to authority, yes, but the
(presumably sarcastic) "lovely" here seems like you are implying that this
is an "appeal to authority" logical fallacy, vs. a legitimate appeal to
authority. It is not, though your position seems strikingly close to the
related "Dismissal of Evidence" [1] form. Rather, FESCo is the community
elected authority intended to make such decisions, and is a perfectly
reasonable authority to appeal to for such decisions.

I think everyone appreciates that there are differences of opinion. The
previous lengthy thread on this list is evidence of that. What matters is
how those differences are resolved. If FESCo is involved to bring
resolution, and then somebody decides to circumvent that decision with a
functionally equivalent implementation as the one that was voted against,
that is a problem.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20141208/351d5977/attachment.html>

More information about the devel mailing list