[Top][All Lists]

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

address@hidden: Re: [security-discuss] gnuradio project DoS attacks GNU

From: ng0
Subject: address@hidden: Re: [security-discuss] gnuradio project DoS attacks GNU wget users]
Date: Fri, 3 Mar 2017 11:08:43 +0000


I don't like repeating myself when I have written the content before.
So going by the message below, I'd like to change the way we provide
download links and use the http protocol for our downloads at Currently we only offer the ftp protocol links. The
ports 20 and 21 are commonly blocked in the tor network by relays, that
I was able to telnet to port 21 of was just luck.

Changing this would make our downloads more accessible than they are now.

If there are no objections I will prepare the patch for the website as
soon as I have time to do it.

It would not fix
the fact that we use ftp:// internally in some downloads (which breaks
guix package --fallback when you try to torify guix), but this could
be fixed later.
----- Forwarded message from ng0 <address@hidden> -----

Date: Fri, 3 Mar 2017 10:54:56 +0000
From: ng0 <address@hidden>
To: Richard Stallman <address@hidden>, address@hidden, address@hidden, 
address@hidden, address@hidden, address@hidden, address@hidden, address@hidden
Subject: Re: [security-discuss] gnuradio project DoS attacks GNU wget users

On 17-03-02 20:08:39, ng0 wrote:
> On 17-03-02 11:50:09, Richard Stallman wrote:
> > [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> > [[[ whether defending the US Constitution against all enemies,     ]]]
> > [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > 
> >   > As far as I perceive it, and the alpha ftp do not provide
> >   > any access to be used from tor exit nodes.
> > 
> > This sounds like a real problem.  Can someone present a specific test case
> > that fails?
> That's as easy as running tor with a configuration where you exclude
> at least exit-nodes located in the USA. Then you will try to download
> any file on one of the download locations of gnu, with a graphical
> webbrowser - it does not have to be torbrowser - you pass it the
> arguments to use the socks5 proxy of tor as described in the torproject
> website documentation, and just trying to establish a connection to
> will fail with "Error: Bad IP connecting".
> I have not checked my config in a while, but this shows that there's at
> least an problem if you connect not from within the USA. I can't recall
> if I ever had a good exit-node connecting to, but I doubt it.

I have a correction to make: after someone else in a conversation told
me that it works for them, I tried to reproduce my problem. THe problem
is just when I use the ftp:// links, everything else works.

Which means, `torify telnet 21' worked as well as
accessing the ftp over `' and `',
previously I assumed the ftp of is still limited to only ftp
port access. So there is a problem with port 21 and maybe 20, but this
problem exists only because a majority of tor relays filter those ports.

I think the only improvement GNU can make is to have a list of onion
services, if GNU wants to. This can be achieved like Debian does with but it can also be achieved with sub domains
to just one onion. For an example take a look at
and where mentions the
onion at the bottom of the page and for the second domain I have
forgotten where the anchor for the "Why not HTTPS" is.

> >   > I find this annoying every time I have to check releases, update
> >   > software for Guix, etc. If mirroring would be an option I would run an
> >   > .onion mirror.
> > 
> > Last I heard we had lots of mirrors.  Making another kind of mirror
> > would be useful too.
> > 
> > -- 
> > Dr Richard Stallman
> > President, Free Software Foundation (,
> > Internet Hall-of-Famer (
> > Skype: No way! See
> > 
> Below I use "mirrors" when I refer to the root download architecture at
>, the exception is the provided mirror which should be clear from
> context.
> If this (whereby I mean providing .onion access at the root level
> of software distribution, the servers) is not or not right now
> possible to be provided by the FSF/GNU[0], I strongly consider to
> provide an .onion mirror with the intention to add .gnu gnunet later on.
> However there are problems:
> * I'm not looking really forward to administrate server(s) again, even
>   if the underlying system makes administration easier.
> * I'm limited in resources both financially and time to invest.
> * My non-commercial ISP of choice is prepared for lots of traffic, they
>   even have some tor exit- and non-exit relays/nodes in their network,
>   but if this mirror would be used it would be a centralization of
>   service which would be an easy target to take down, in addition to
>   testing out how much traffic is okay for their infrastructure. Last
>   time I ran an tor non-exit relay in there it was still okay with
>   several TB of data per month.
> I know I can just mirror some (and not all) mirrors of, reducing
> the size which is needed. At the current size of all mirrors
> this results in ~125GiB. Taking in consideration the operation system to
> add and that at IN-Berlin eV (the ISP) you can only buy disk space in 25
> sizes (n times 25) I get less than 20 Euro / month.
> Now the consideration of the choice of datacenter vs "other places" and
> therefore the choice of machine in use is how much electricity is
> wasted in the process.
> I have to think about compromisses of use vs costs as the ideal solution
> would be to also provide a service for binary substitutes similar to
> what's offered from at the moment.
> 0: I'm not sure who's responsible for the server maintenance, I know
> both parties are involved depending on the level of maintenance.

----- End forwarded message -----

reply via email to

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