@eyedeekay
&eche|on
&kytv
&zzz
+R4SAS
+RN
+RN_
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
An0nm0n
Arch
Danny
DeltaOreo
FreefallHeavens
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest42386
Irc2PGuest5995
Leopold_
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy
Soni
T3s|4_
aargh2
anon2
b3t4f4c3
bak83
boonst
cumlord
dr4wd3_
eyedeekay_bnc
hagen_
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
x74a6
R4SAS
zzz: will you add my tracker to snark?
RN
users can add in config. I have yours configured in my snark, R4SAS
dr|z3d
I think he knows that, RN. He wants to be default. :)
R4SAS
not default, just "out of the box"
dr|z3d
which is default in Snark for opentrackers.
dr|z3d
all opentrackers are used by default.
R4SAS
as I see, TheBland is dead now
R4SAS
same for omitracker
R4SAS
so only skank, dg2 and postman (closed) are alive
dr|z3d
and R4SAS, don't forget that one. :)
R4SAS
Mine is not in default lists))
dr|z3d
omitracker is intermittently up, anyways, though not reliable at this point.
dr|z3d
you're a default in I2P+ Snark.
R4SAS
ok
R4SAS
same for XD
R4SAS
I'm thinking about digging into xbtt
dr|z3d
what is it? another client?
R4SAS
to make another cracker
R4SAS
tracker**
dr|z3d
I thought you were digging into templates *cough*
dr|z3d
can't get excited about open trackers. they're perfunctory :)
R4SAS
xbtt is most used tracker anyway, neither than opentracker
dr|z3d
what I could get excted about is a DHT search feature, however, with some blacklisting to remove the nasty stuff from the index.
R4SAS
opentracker stores everything in memory, so restarting makes pain in losing everything what was stored
dr|z3d
sure, same on java.
dr|z3d
it also likes to be fed RAM.
R4SAS
you about zzzot?
dr|z3d
am I talking about zzzot you're asking. if so, then yes.
dr|z3d
which iirc was ported from opentracker.
R4SAS
zzzot is the same opentracker, from 2008
dr|z3d
with some mods along the way, but sure.
dr|z3d
this one for example on skank: opentracker.skank.i2p/hashes
R4SAS
I have disabled fullscrape to avoid hash leaking
dr|z3d
no fullscrape on skank either.
R4SAS
your /hashes/ can be called as same as "fullscrape", if every active hash is printed here
dr|z3d
they're not, view the page and you'll see.
R4SAS
btw, what is btdigg.i2p?
dr|z3d
only hashes for active torrents.
R4SAS
anyway, that is LEAK
dr|z3d
btdigg appears to be a clearnet dht search engine.
dr|z3d
I disagree, you have no expectation of privacy when using an open tracker.
R4SAS
one thing is when you getting info about know only to you torrent hash, other is when anybody can see your torrent hash
dr|z3d
if you want privacy, then I guess you either mark your torrent private or run your own tracker an opt out of dht/opentrackers.
R4SAS
usage of opentracker of course can be called as leakage, because no one knows if owner can see that hashes lists
dr|z3d
if opentracker was called supersekritprivacytracker then I'd probably agree.
R4SAS
but anyway, ability to look at all hashes is worser
R4SAS
to look to anyone*
dr|z3d
sure, a full scrape is also a substantial amount of data on an active tracker.
zzz
I guess I'll have to install and run bigly to catch it, unless somebody else is running it
dr|z3d
RN runs bigly afaik. maybe ask her?
dr|z3d
and set the minimum announce interval so you're not sitting around waiting.. :)
zzz
it will just randomly scrape whatever it's announcing to?
dr|z3d
yeah, I guess
dr|z3d
dunno if it's random or it does both a scrape and an announce at the same time.
zzz
dr|z3d, plz check your zzzot jetty logs, are the fetches for /tracker/a/scrape and /tracker/scrape, or for /a/scrape and /scrape ??
dr|z3d
the latter, zzz. at least that's what's reporting in the wrapper logs.
zzz
thats why I'm asking about jetty logs, because the wrapper logs might be relative to /tracker/
zzz
trying to figure out where to log this because it's blowing up outside of our jsp
zzz
running bigly and zzzot, can't reproduce
zzz
nor do I get any 400 back from your tracker or dg2, for any manually-entered url / params via browser
dr|z3d
oh, hang on, let's see if org.eclipse.jetty works, it was set to org.eclipse.jetty.server
dr|z3d
nope, same, nothing in router logs.
dr|z3d
urls are appearing currently 2 at a time:
dr|z3d
INFO | 2024-03-25 21:44:55.268:WARN:oejs.ServletHandler:Zzzot Jetty-265215: /a/scrape
dr|z3d
INFO | 2024-03-25 21:44:55.248:WARN:oejs.ServletHandler:Zzzot Jetty-251494: /scrape
zzz
dr|z3d, but jetty is returning response code 400 when it happens, you see 400 in the request logs, correct?
dr|z3d
"GET /a/scrape HTTP/1.1" 400 6703 "-" "BiglyBT"
dr|z3d
"GET /scrape HTTP/1.1" 400 6701 "-" "BiglyBT"
zzz
ok thanks
zzz
I've never gotten a 400 via manual tests with constructing urls in the browser. Not on yours or mine or dg2 zzzot.
zzz
nor by pointing biglybt to my zzzot
zzz
next to try is pointing it at yours
zzz
see github.com/BiglySoftware/BiglyBT/issues/3211 I just entered for the /a/scrape thing
dr|z3d
ok
dr|z3d
longshot, but maybe the torrent name is using doublebyte characters.
zzz
I also pointed bigly at a non-tracker tunnel just so I could look at the http headers, nothing unusal
zzz
the only param for a scrape is info_hash
dr|z3d
yeah, ok, thought as much right after I typed that.
dr|z3d
plenty of "GET /tracker/announce.jsp HTTP/1.1" 200 55 "-" "BiglyBT" in the logs as well, so bigly isn't failing all the time.
dr|z3d
I can confirm that the same client is requesting both scrape and announce urls.
zzz
and whatever forkage you may have done, you haven't accidentally deleted the line:
zzz
request.setAttribute("org.eclipse.jetty.server.Request.queryEncoding", "ISO-8859-1");
zzz
at about line 78 in scrape.jsp
dr|z3d
are you asking?
zzz
yes
dr|z3d
I see that here in both local copies at around line 33.
dr|z3d
// so the chars will turn into bytes correctly
dr|z3d
request.setCharacterEncoding("ISO-8859-1");
dr|z3d
// above doesn't work for the query string
dr|z3d
// we could also do ((org.eclipse.jetty.server.Request) request).setQueryEncoding("ISO-8859-1")
dr|z3d
request.setAttribute("org.eclipse.jetty.server.Request.queryEncoding", "ISO-8859-1");
dr|z3d
java.io.OutputStream cout = response.getOutputStream();
dr|z3d
response.setCharacterEncoding("ISO-8859-1");
dr|z3d
response.setContentType("text/plain");
dr|z3d
response.setHeader("Pragma", "no-cache");
dr|z3d
String info_hash = request.getParameter("info_hash");
dr|z3d
String xff = request.getHeader("X-Forwarded-For");
dr|z3d
String xfs = request.getHeader("X-Forwarded-Server");
zzz
that looks right
dr|z3d
yeah, aside from adding a tracker hash page, I don't think my version of zzzot diverges much, if at all, from canon.
zzz
ok I just reproduced it on your zzzot, finally
dr|z3d
aha, progress!
zzz
I believe your attempt to disable full scrape via jetty config has gone wrong
zzz
/scrape w/o an info_hash param redirects to home page
dr|z3d
ok, let me review that. I'll paste the relevant section here.
dr|z3d
been years since I looked at it.
zzz
/scrape with an info_hash param gets the 400
zzz
I suggest you back out whatever you did, and merge my full scrape config option checkin from 2022
dr|z3d
it appears all I did was comment out the RewritePatternRule for scrape in jetty.xml
zzz
because /scrape?info_hash=... returns 400
zzz
but /tracker/scrape?info_hash=... works fine
zzz
so as suspected, the home page isn't prepared for a non-utf-8 param
zzz
so you're prohibiting all scrapes, not just full scrapes
dr|z3d
apparently so.
zzz
but only for /scrape, not for /tracker/scrape
dr|z3d
yeah, all of those defined in that RewritePatternRule section
zzz
so assuming you don't have anything against 1-torrent scrapes, back out the jetty.xml changes, and make sure you have my 2022 full scrape checkin applied
dr|z3d
yeah, that's what I figured. thanks. and sorry for the distraction.
dr|z3d
if we default to false for the hashlist feature with a config, you interested in a patch, zzz?
zzz
patch that does what?
dr|z3d
patch that does this: opentracker.skank.i2p/hashes