-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 2018-02-15 19:21, Fungal-net wrote:
> 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.

For any packages that aren't devuan specific, amprolla3 just makes a
HTTP 302 redirect to the corresponding debian server. It doesn't try
to access the file from the debian server at any point, the client, in
this case apt, has to follow the redirect and make a new request to
the debian server. If apt reacts differently when a request fails
after a redirect, which I don't know if it does, that would be a bug
in apt. Of course, amprolla has to merge the package lists, but the
package list is always the same no matter how you access it, and it is
a normal file on the server that's not newly generated for each
request. It also doesn't matter where it gets debians package lists
from, since they should be the same everywhere. And of course, any
file located directly on pkgmaster is the same no matter if you access
it over http, https or the .onion address.

> 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.

I've used tor and the onion address for a long time now, and I haven't
had any issues so far. But debian offers different mirrors for http,
https and tor, so there is always a slight chance that only a few of
their mirrors run temporarily into issues, which could cause only one
way of accessing it to temporarly cause problems.

> 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.

I did notice that change too, it was a long time ago, but even though
it would have been nice to know in advance, it did not make any
notable difference for devuan jessie, and devuan ascii wasn't even in
beta at that time. If anything, I'm glad they made the change, because
even though there have been minor issues with very few ascii packages,
not using pkgmaster would have caused even more problems, some
problems had to be expected from something not released yet, and these
problems have been widely known, were easy to fix, and had to be
expected. I guess someone should make a small notice on the web page
that the .onion address goes to pkgmaster and not to auto.mirror, but
it'll probably soon no longer matter anyway, since amprolla3 probably
replaces amprolla anyway, or are there plans to keep both running?

> 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!

No, from everything I have seen so far, the onion address and
pkgmaster are definitely the same server*.

And it's absolutely necessary to make the http redirects to the http
debian repo, the https redirects to the https debian repos, and the
.onion redirects to debians .onion repos. You see, the different ways
to connect to the repos cover different threat models. One may want to
use http if he intends to use one of a pool of mirrors, and there is
noone causing trouble (like ISPs inserting ADs for example). One may
want to use HTTPS if there is someone causing trouble. One may want to
use tor if he either wants a direct connection to the server, since
they don't trust all their Certificate Authorities etc., or if they
need to stay anonymous. Most .onion sites don't provide SSL
certificates, since the connections are already end to end encrypted
anyway, so they use http instead of https. But if we were to
unconditionally make the redirects to debian servers to their http
mirrors, a bad exit node could cause problems and, for example, delay
new packages and updates. Similarly, redirecting https to http
wouldn't work, since bad ISPs could cause problems again. Just always
using https for the redirects won't work either, since people using
http would probably need apt-transport-https, and people using tor
would have to trust the CAs again.

* Assuming no government agency or big company are intercepting the
connection. Since some companies like facebook are capable of brute
forcing a whole onion address (like facebookcorewwwi.onion), if
someone manages to get the same one as devuan has, I assume they could
intercept some traffic. But I think Tor has plans to increase the
address length, so this will probably be fixed soon.

> 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.

Actually, no, that wouldn't work. A tor exit node never knows the IP
of the entry node, except maybe if all nodes you are using are under
the same attackers control, but in that case almost the whole tor
network would be compromised. The most common way to compromise tor,
aside from trying to get lucky with traffic correlation, would be to
compromise the client itself. Most people install tor on the same
machine they use it on, and do only route certain traffic through it.
Many intelligence agencies use this by tricking users to use a program
whose traffic isn't routed over tor in order to figure out their true
IP. For example, a user may anonymously download a movie over the Tor
Browser, but play it using a video player whose traffic isn't routed
over tor, and if that Video contains DRM or anything else that makes a
connection to an outside server, they can correlate your tor session
with your IP. This is why I use tor only as a transparent proxy in a
specially prepared isolated network instead of letting it run directly
on my machines. The redirects shouldn't be an issue with
apt-transport-tor, since it must route everything through tor if the
tor transport is used, but if you use apt-transport-tor and don't
route really everything through tor, you'll still need to trust the
package maintainers, etc. Thinking of this, it would probably be
pretty easy to take over debians buildd infrastructure, since noone
can possibly completely read the build scripts for every package, but
I'm getting sidetracked again.

> 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!

I can't remember any problems that haven't been publicly discussed on
the mailing lists, IRC and the forums. There is also a nice bug
tracking system and a connected mailing list which gives a nice
overview over the things that have been done and that have yet to be
done. There may have been that one minor mistake once a long time ago,
but I think making such a big deal out of it is a bit of an overreaction.
-----BEGIN PGP SIGNATURE-----

iQFIBAEBCAAyFiEEZT8xKpcJ1eXNKSM1cASjafdLVoEFAlqGQNoUHG1lQGRhbmll
bGFicmVjaHQuY2gACgkQcASjafdLVoG38gf+M6O+xzlUJxTk8mqyvBgzFTwXleDk
eWsDNUtEMfeDVh18aocSbaJb5OGHY2fcIduqITehaAVB/csVyNbdF7amhQy3bPjN
gArsasJ9QDVlbpX1HfxcKxfYt5qpwI1qvfjzDrYqtnYIcIvJLQiGZ76WWM58PJAh
dP2y6TThSEfypOb8bV2BgBsQEPB2iGttiEgGZg9ZdNMMo8LbVH68JVDx/5J3nnYF
CIwx98lbjOX7+DfU4eDKRS7/zD6ILEajDspY2eTmdsXlGzPhjKfqZ9r/Iy7JdifD
GmkOfvBp4cjzjmHYf5x7CCCmqWI5lGgZCDRzMOT734Q9d2dmkS9PAbzNvg==
=oBbI
-----END PGP SIGNATURE-----
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to