:: Re: [DNG] devuanfwojg73k6r.onion an…
Top Page
Delete this message
Reply to this message
Author: KatolaZ
Date:  
To: dng
Subject: Re: [DNG] devuanfwojg73k6r.onion and pkgmaster.devuan.org are they and have they ever been the same?
On Thu, Feb 15, 2018 at 02:21:39PM -0500, Fungal-net wrote:
> If we are talking about the technical problem (which did exist) let's talk about the technical problem.
> If we are talking of the political/security problem let's talk about that. But don't try to make soup out of what we are talking about, and it is to your interest to try to understand criticism, despite of the form it is coming from.
>
> Today, and after a lengthy discussion on the onion repository malfunction, based on the "new" evidence Katolaz has provided us, there is a speculation of the source of the technical problem. Again and again and in several machines and users the problem appeared as "pieces" of the repository been missing. Stuff that was in there the day before would be missing but the rest would be there from both devuan and debian, and there would be no "error" in updating repositories.



Which pieces of the repositories were missing exactly? Why are you so
reluctant to provide evidence to substantiate your claims?

>
> A    It seems as obvious now that when amprolla3 tries to merge from debian.onion debian has some amprolla like merging system of its subrepositories (not all in a single server).  Some of them may be timing out, and amprolla3 is not forwarding those errors as partial hits.


Nothing like this happens, at all. Please read the code at:

https://git.devuan.org/devuan-infrastructure/amprolla3

>
> B    Using tor://pkgmaster. ...    amprolla3 is hitting the deb.debian.org (or some other clearnet address) and it never runs into timing out issues, so tor://pkgmaster is always in tact and consistent.  It seems as in the past 2 weeks someone must have realized what is going on and went in and adjusted the timeout threshold, which explains the current consistent results.  Or else, there is a limit to how much I can speculate, but something seems to have gotten fixed.

>


Nothing like this happened, at all. We have not "fixed" anything,
since there has been no evidence of inconsistencies signalled by any
of the hundreds of Devuan users who access the repos via tor.

Please go through the commits in the repo above since October (those
are publicly available, checksummed and verifyable), and you will
realise that they are mostly about minor fixes that have nothing to do
with "missing pieces of repos" when accessing the servers via tor.


> C    The political/security issue is that we (users) have been in the blind.  
>    1   When someone chose to shift the onion repository address to pkgmaster (a beta system) someone should have made an adequate announcement and such was never made, not in the webpage not in the "officially official forum" that no developer has ever visited.  


This might have been the only mistake on our side, but was done in
good faith. Could you please point to the specific breakage that this
has caused to you (something that you still refuse to do)?

>    2    If the admin of the pkgmaster.devuan.org can distinguish whether a connection is using onion or clearnet (apart from tor, they are not the same you know, you can use tor to access any clearnet address that has not blacklisted all exit nodes, but you can not use http/https to reach an onion address) either the server on the onion address is a different server (as allowed to conclude by differential parallel results) or it is forwarding those connections to "other" servers.  That ability to distinguish the two and act based on that distinction is problematic!


You won't believe it, but it's much simpler than that: your http
client sets the "Host: " header to the FQDN of the server you are
contacting. This is how 99% of the web is working nowadays. There is
no magic involved, only standard HTTP protocol: when you use a onion
address, the server you contact is requested to serve the content
associated to that onion address. The server reads that header, and
serves you the corresponding content. Please refer to RFC 2616:

https://tools.ietf.org/html/rfc2616

Amprolla works using HTTP rewrites, we have never concealed that. If
you don't like this, you should not use Devuan repos.

>    3    If a tor connection is made through the tor network and out in the clear, and back into tor again (as described by Katolaz) then according to torproject the identity of the user can be revealed.  They don't know how it happens, they can't yet explain it, but they have warned and reported this for a long time.  People abused the abilities of tor and it creates vulnerabilities that can't be controlled.  Imagine  a server running tor and feeding an IP to another machine and that other machine is running tor a second time.  The identity can be revealed, and I don't need to explain to whom or why.

>



In order to remain "concealed", your connection should be made to the
onion address, not directly to pkgmaster.devuan.org. If you do so,
your requests for packages that are coming directly from Debian are
redirected to the Debian onion address. There is no magic involved
here, only standard HTTP protocol and standard tor functioning. Please
refer to RFC 2616:

https://tools.ietf.org/html/rfc2616

>
> So, thank you, I (we) have been convinced here that "unfortunately" we have been right all along, we did our best to report and alert of the problem, partially the problem seems to have been silently fixed, but "admins" chose to try to shove things under the carpet and maintain a code of silence about it till things become explosive. Because when someone is telling you, hey buddy you have a problem. Hey buddy, this is the problem you have, and the only response is "there is no problem, you are crazy", then morally one is obliged to make noise and alert victims of the problem denied by authority!
>
> Good bye, and try to be more social when you receive constructive criticism. Something that seems to have been long gone in linux environment.



Constructive criticism must substantiated with technical evidence,
that you still fail to provide, after many requests. If this important
ingredient is missing, the "constructive criticism" becomes a "useless
rant".

So good bye.

>
> PS To those asking MORE technical evidence, go to the officially official devuan forum and you will find all the specifics. Ask fsmithred to point it to you as he was the only one that took attention and tried some things out to figure it out for himself. Unfortunately by the time he did the problem was cured. When half the dependencies were missing for installing eudev and openrc in ascii he couldn't tell why it was happening.
>
> PS2 alessandro ... I am surprised with this attitude you got so far (linux.com) ... but talking with that tone should be reserved for up close conversations you spineless piece of shit hiding behind a terminal. I'll see you at some conference and we can continue.
>
>


I guess you should be more careful when publicly threatening a person
in this way. The archives of this mailing list are public,
timestamped, backed up, and freely accessed on the web.

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]