security-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[security-discuss] state of gnuradio freedom and security issues (was: g


From: Anonymous
Subject: [security-discuss] state of gnuradio freedom and security issues (was: gnuradio project DoS..)
Date: Wed, 8 Mar 2017 09:45:49 -0500 (EST)

Dr. Stallman said:

> We've cleared up what the situation is, and where the FSF stands in
> regard to it.  We have found a couple of real problems, and
> sysadmins are working on the ftp.gnu.org problem.  We've explained
> the situation clearly.

There are still several unaddressed issues here.  Speaking strictly
about software freedom and not security or civil liberties, here's the
concise summary of the past couple months:

problem 1) Freedom 0: GNU Radio Foundation, Inc. ("GRFI") is stopping
           GNU wget users, lynx, and cURL users from using their
           browser software (wget, lynx, and curl) how they want in
           the course of obtaining the GNU Radio manual.

   Attempts to block solutions to problem 1 consist of this rationale:

     1.1 GRFI is not stopping gnuradio users from using gnuradio how
         they want.  (that is true, but it's obviously a red herring;
         this same line of reasoning appeared many times with
         different wording)
     1.2 Freedom 0 "applies/corresponds" to software not people.
     1.3 Authorship solves this.
     1.4 At least one free application can access the content.

problem 2) GRFI violates the GFDL requirement that the manual be
           distributed with the software.

   Attempts to block solutions to problem 2 consist of this rationale:

     2.1 Documentation is included with the application.
     2.2 It's the preamble that's being violated, which is only an
         overview of goals, and therefore not enforceable.

problem 3) GRFI violates the GFDL requirement that the manual be
           available in a simple format.

   Attempts to block solutions to problem 3 consist of this rationale:

     3.1 Simple HTML is just an example (a suggestion), not an
         enforceable requirement.
     3.2 The rule about having a simple format is not for the benefit
         of readers, it's exclusively for developers who modify the
         manual for redistribution (Paolo).
     3.3 It's impossible to create a non-ugly website with the search
         functionality offered without departing from simple HTML to
         use javascript.
     
For the security matters, we also have:

problem 4) The GRFI is DoS attacking (and discriminating against)
           users of GNU wget, lynx, and cURL.

   Attempts to block solutions to problem 4 consist of this rationale:

     4.1 DoS is defined differently.
     4.2 GRFI is trapped, they have no choice, they must use
         CloudFlare for security.
     4.3 Tor has a hand in the problem.
     4.4 CloudFlare is the perpetrator, not GRFI.
     4.5 CF is using heuristics and not blanket-blocking.
     4.6 It's okay to discriminate because that group has some bad
         apples.

Point by point, this is the state of the rationale above:

1.1 This statement appeared several times with different wording.
    It's a true statement, but it's obviously a red herring because an
    issue was never raised about freedom 0 w.r.t the gnuradio
    application.
1.2 This was an equivocation fallacy.
1.3 It was not explained how authorship solves the problem, and
    dismissed as a red herring.
1.4 It's a true statement and remains undisputed.  Someone should
    dispute this though, because imposing a tool that works for some
    users on all users neglects the spirit of freedom 0.*
2.1 Challenged because bundling some documention and not all official
    documentation is a circumvention that can be taken by any creator
    claiming "the source code /is/ the documentation", which would
    render the license useless.  That point defeats 2.1 and remains
    uncountered.
2.2 Challenged because 1) a court would unlikely effectively toss out
    the whole license and ignore intent, and 2) even if it did,
    freedom-respecting people involved on solving the problem should
    act with higher freedom standards than the court.*
3.1 The suggestion maps back to a real requirement (see 3.2).
3.2 Paolo's point remains unchallenged.  It may be correct.  But why
    would users not have the right to receive a transparent copy
    simply for reading and not updating?*
3.3 The GFDL favors simple HTML over pretty pages.  Filip Brcic then
    said it's a DoS against non-lynx users to remove the javascript.
    I think Filip remains uncountered.
4.1 There was some equivocation over DoS vs. DoS attack.  4.1 was
    defeated and there were no counter arguments.
4.2 The majority of the web still functions without CloudFlare, and
    gnuradio.org has no special needs that require CF.  This point was
    not yet countered.
4.3 Victim blame attempt was countered and that counter still stands.
4.4 GRFI hired CF, and through that decision has responsibility for
    the problem.
4.5 This was countered because CF is in fact blanket blocking
    gnuradio.org visitors (tor is not whitelisted).
4.6 The discrimination is both needless and unjust.  This remains
    uncountered.

No new ideas were introduced above for the most part.  Exceptionally
three new counter arguments have been marked with an asterisk ("*").

> The remaining dispute seems to be based on misunderstanding of our
> terminolgy.  If someone wants to continue trying to clear these up,
> it needs to be done in the spirit of listening, not disputation.

The core issues are fundamentally a dispute.  People have taken
positions, and argued civilly (no ad hominems), which is how it should
be.  What's inherently wrong with discussing a dispute?  You seem to
suggest that disputation is inherently at odds with listening.  I
think not.

Certainly there was a lack of listening, but this is not inherent in
debating the issues.  It's more a function of the degree of the wisdom
of participants.  When someone repeats a defeated argument without
addressing the points of contention that defeated it, that shows lack
of listening.  If that was done on my part, feel free to cite points
that I've missed (I am listening).  In cases where I had to repeat
myself, it was something that was overlooked or brought up again
without addressing the actual points of contention, which also
indicates lack of listening.

> How about if someone does this off line?

Certainly for the security matters, this is an unsolved problem.  To
"take it offline" implies a private exclusive discussion, which
excludes the general public from working on the problem.  I find that
ineffective.  The lack of a solution implies that broader exposure is
needed, not less exposure.

I will try to monitor the free.software and comp.security.misc
newsgroups if anyone wants to continue the discussion relevant to
those venues.

--
Please note this was sent anonymously, so the "From:" address will be unusable.
List archives will be monitored.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]