-
gingeropolous
selsta> Yes, after a timeout. But malicious nodes don't know which hop they are so they can't say with certainty the source IP. <<< if they see tx B in their subnet, and then never see tx B in the rest of the monero network, then they can presume it came from the node connected to their node
-
gingeropolous
because otherwise the failsafe would cause an honest node to fluff
-
gingeropolous
i wonder if we should leverage the centralization of seed nodes to provide block lists
-
gingeropolous
i mean, if a list of IPs *to* connect to is fine, why not a list of IPs *not to* connect to?
-
selsta
gingeropolous: I don't follow. What do you mean with subnet?
-
selsta
Let's say A, B are legit nodes, C is malicious. Tx goes A -> B -> C -> blackhole, then B has the shortest timeout timer and broadcasts it to the network
-
selsta
how does C know A is the original node for that transaction?
-
moneromooo
The timer is random (within a given distribution).
-
selsta
right
-
selsta
was just an example
-
moneromooo
I think gingeropolous' point is that if A send a tx and is connected to only Eve's sybils, then if Eve drops it all, if Eve gets the tx again from A, it's more likely A is the sender.
-
moneromooo
Which seems like a fair guess.
-
moneromooo
A might have been the one with the shorter timeout though. Can't know.
-
moneromooo
Actually, there's one way to know for almost sure.
-
moneromooo
If Eve's sybils have 12 incoming connections to A.
-
moneromooo
Then it's pretty likely A has no other connections if it doesn't accept incoming connections (many don't, and it's easy to check).
-
moneromooo
Defense against this would be random max out connections, and ensuring you accept incoming connections.
-
gingeropolous
yeah, my point was if A send a tx, and is connected to C, and C is a sybil, C can blackhole the tx and monitor the rest of the network and deduce that A was the sender if it doesn't appear in the txpool (i.e., if it doesn't get notification of this tx again)
-
gingeropolous
right? Or does A fluff the tx as well after a timeout? the originator of the tx?
-
moneromooo
A does.
-
gingeropolous
ok, so A can fluff after a timeout.
-
gingeropolous
well yeah, then what you said holds true
-
gingeropolous
<selsta> gingeropolous: I don't follow. What do you mean with subnet? <<< the attackers collection of AHPs that are highly interconnected with each other
-
kayront
something tells me these nodes are more than a mere annoyance. i mean, it's not like there are hundreds of thousands paying in monero getting stranded at payment terminals -- usually a delay of a a few minutes ,or worst case the full timeout, isn't the end of the world. annoying yes, especially if it doesn't stop happening.. but go through all that job to annoy people paying XMR in situations that are mostly time critical? i mean.. it's
-
kayront
possible, but my gut tells me it's smt more
-
kayront
that job -> that work
-
kayront
from the bits and pieces i've picked up in conversation here, it seems that d++ might have inadvertently magnified whatever funny business is happening here - that according to selsta (iirc) was already happening before, but has now become more noticeable. that seems like a fortuitous (for the bad actor) coincidence.
-
kayront
if i understand correctly, there is a good chance that unless this issue is mitigated, it will remain a reality at the discretion of the attacker(s)
-
kayront
i wonder why the bad nodes mirror block height (someone mentioned it yesterday). perhaps an interesting workaround could be, rather than banning nodes who do that, blacklist them ourselves (if that's what the ban command already does, then ignore this suggestion)
-
sech1
At the very least these nodes watch transaction propagation to associate IP with every transaction
-
sech1
This is why they try to connect to every single legit node on the network, and they connect in big numbers
-
» moneromooo constantly gets this scene from spaceballs... Just how many assholes do we have on this ship anyway ? "YO!"
-
xmr-pr
moneromooo-monero opened pull request #6936: protocol: detect and drop asshole peers
-
xmr-pr
-
kayront
selsta: was it you that linked a list of evil peers yesterday? i can't seem to find it
-
moneromooo
-
kayront
thanks
-
gingeropolous
need that i2p built in!
-
Lyza
I want it so bad
-
asymptotically
would everyone using i2p/tor not make a sybil attack easier? since then you can't just block an address block or asn
-
gingeropolous
i don't think it would help the sybil, but it would mitigate: "<sech1> At the very least these nodes watch transaction propagation to associate IP with every transaction"
-
Inge-
moneromooo: Major asshole, reporting for duty!
-
moneromooo
Keep firing, assholes!
-
xmrscott[m]
FYI since dsc is bringing it up, conversation about using something other than GitHub/GitLab:
monero-project/meta #522
-
xmrscott[m]
Snipa: ^
-
hyc
I'm in favor of anything that isn't github...
-
xmrscott[m]
Yes, I mean the youtube-dl scandal probably speaks a great deal to folk here
-
selsta
I'm tired of this conversation :P
-
Snipa
Self-hosted is great, but then you're at the mercy of the upstream provider still.
-
Snipa
Who's at the mercy of their upstream ISP.
-
Snipa
Etc.
-
selsta
We use both Github Actions / Travis CI which both don’t get supported by Gitlab / Gitea
-
Snipa
If you want to make the statement "Get out of the US", then you need to start by finding a non-US datacenter provider that matches your requirements.
-
Snipa
Tbh, it's pretty trivial to require GA/TCI into GL CI/CD.
-
Snipa
I use GL CI/CD on a daily basis for work, and it's pretty much "if you can write a shell script, you can stuff it into gitlab-ci"
-
hyc
re: CDN breaking ssh - do we actually need a CDN to frontend the repo?
-
selsta
gitlab does not support enabling CI for all users
-
selsta
we tried this already with the sites repo
-
Snipa
Sure it does?
-
Snipa
The issue is disabling it for some users.
-
Snipa
:P
-
hyc
why does ssh work with github - they use no CDN?
-
Snipa
They intercept and reroute the traffic at the CDN.
-
Snipa
Like a sensible company would do, if they talked to their CDN provider.
-
Snipa
Generally though, I just use a second SSH address, and tell gitlab to use the SSH address when displaying it.
-
hyc
which means ssh could be overloaded by high volume
-
Snipa
Usually. Generally, you'd block SSH for anyone except who's got access to push.
-
Snipa
As you should be pulling either packages or over HTTPS.
-
Snipa
Both of which get cached at the CDN layer.
-
moneromooo
The ssh thing could have been done, but required me to configure cloudflare stuff, and I'm not touching it because they're either a TLA in disguise, or pwned by many of those. Either way, they should be dropped by anyone who cares.
-
moneromooo
ssh worked well with the actual IP. IT was just blocked by cloudflare.
-
hyc
so, do we just forego cloudflare, setup our own squid proxy or whatever if we need to put a cache in front?
-
Snipa
Tbh, in my eyes, the argument is kind of absurd. Moving off GH would be nice, but we've also very happily integrated into GH.
-
Snipa
If there's a serious want to move away from GH, move issues/bug reporting first, and figure out if there's going to be someone to run that infrastructure.
-
Snipa
Step 1 is to de-couple, not look for a full blown replacement.
-
hyc
good point, that can be a major pain. we migrated openldap from our old tracker to bugzilla recently
-
hyc
and exported and re-imported all of our old bug DB, so nothing was lost
-
hyc
otherwise it would have been a non-starter
-
moneromooo
IIRC github had (maybe still does for now) an exporter for non repo data.
-
Snipa
I mean to selsta's point: We've got CI/CD to worry about, both of which are stated not to work with the fastest drop in solution (Self-hosted gitlab). Which means that we need to be concerned with: MR's, Tickets/Bug Reports, CI/CD systems.
-
moneromooo
So someone who cares about htose should probably keep an eye on that, keep an update export for the time MS goes evil (which, historically, they will).
-
Snipa
All of which need to be de-linked from the way we work with GH if this is going to go forwards, because the other solutions are just going to end up with: Well, we've integrated with X, and now we're dependant on X.
-
Snipa
Because that's /really/ the point of this arguement I suspect.
-
Snipa
MS always goes evil. Remember. Embrace. Extend. Extinguish.
-
ErCiccione[irc]
thanks moo
-
ErCiccione[irc]
We needed a paid plan to have CI working for all users on gitlab. Otherwise each user needed their own runner. And each users would have counted as member of the project, and we had to pay a plus for each member. I'm going by memory
-
selsta
We already have full regular backup of our repos
-
Snipa
Gitlab also has full licenses available for open source projects.
-
Snipa
Which I know I pointed out last time, and someone was going to look into.
-
selsta
(repos + metadata)
-
Snipa
Also, as we'd want to self-host, why the hell does it matter, as you tie your runners to your self-hosted instance.
-
hyc
Yes, openldap is on a full license, free.
-
Snipa
Because gitlab is still functionally centralized like GH if you use the cloud version.
-
hyc
it still requires annual renewal, but it's free.
-
ErCiccione[irc]
yeah, i remember that snipa. no idea if somebody did look into that?
-
selsta
Who will pay for the self hosted CI?
-
selsta
Who will set it up? I will not
-
Snipa
Tbh, someone's got to pay for all of this crap if we move off GH.
-
ErCiccione[irc]
iirc rehrar said was going to contact them at the time. Rehrar am i correct?
-
Snipa
Besides, like I said, with a self-hosted GL instance, the issue is moot.
-
Snipa
Your self-hosted runners tied to a self-hosted GL instance will work for all users properly configured.
-
selsta
I really don’t like that we tried moving to Gitlab, it was kinda meh and now we are discussing this again lol
-
ErCiccione[irc]
To be fair, the issue is not about moving to gitlab, but to gitea
-
Snipa
All answers are meh.
-
moneromooo
We still have the gitlab instance from pony. Still running.
-
Snipa
Because we're tied to github.
-
moneromooo
There's this cloudflare thing still though :P
-
Snipa
Until we de-link from github and sort through it, it's not going to be solved.
-
hyc
selsta: we can resolve this conversation now, or wait until M$ has a reason to takedown the project
-
selsta
-
selsta
in the unlikely case that monero repo gets taken down we can import it to a different place
-
hyc
accessible only to core team?
-
hyc
in the event that the repo is taken down, we will need to setup in a different place with quite some urgency
-
hyc
whereas right now we can take our time and investigate the best options
-
Snipa
Functionally, GH to self-hosted GL, without being behind CF is the /fastest/ option.
-
rehrar
nobody liked our GL though
-
selsta
pushing the repo to a different place is trivial
-
rehrar
ErCiccione[irc]: this I don't recall but it's very possible it got lost in my mix
-
selsta
the issues / pr history is a bit more work but nothing unsolvable
-
Snipa
Yes, but the infrastructure around it is not.
-
Snipa
Which is the point I've made above. If this is a serious discussion to be had, it's time to start looking at what exists around GH that needs to be moved to a self-hosted service.
-
Snipa
And work out who the hell is going to maintain those services long-term.
-
Snipa
To your point: Travis CI is owned by a US conglomorate.
-
Snipa
So that needs to be removed as well.
-
Snipa
Purchased last year by Idera, which is a B2B parent company based out of Houston Texas.
-
ErCiccione[irc]
Any opinion about Gitea? The issue mention moving specifically to that
-
Snipa
Tbh, if we're going to make the move, my preference would be to stop using large, combined software packages.
-
Snipa
And suck it up, use multiple smaller systems.
-
Snipa
Ticketing/issue management belongs in it's own system. CI/CD should be split apart and only depend on the ability to pull in from an upstream repo, etc.
-
selsta
Snipa: we want to run CI on every PR
-
hyc
... /me muses on using NNTP as backend for bug tracker
-
Snipa
Cool, Gitlab literlaly supports that natively.
-
selsta
Self hosted runners?
-
Snipa
Yes.
-
Snipa
Because when you PR to the upstream, you tie the runner to the upstream.
-
Snipa
ANd it doesn't care any more that the child is pulling it in.
-
Snipa
But you do that on self-hosted, or you don't avoid the core problems listed in the ticket.
-
ErCiccione[irc]
i remember that being problematic at the time
-
ErCiccione[irc]
and was one of the main reasons for moving away
-
moneromooo
hyc: you mean, LMDB having a bug would be news ? :P
-
hyc
:P
-
ErCiccione[irc]
We tested it quite a lot, so i'm sure it was a problem at the time
-
Snipa
Naturally, and I use gitlab in that fashion on a daily basis, so I know it works fairly decently for that.
-
Snipa
But again, I'd suggest moving away from the large combined package.
-
luigi1111
losing github in the future be an inconvenience. why would we go through a similar inconvenience now for a hypothetical?
-
selsta
right
-
rehrar
to be a pure FOSS project bro
-
Snipa
Planning around it is not the /worst/ thing.
-
Snipa
Executing on it poorly is a horrid idea.
-
rehrar
and no, fireice spies, I don't mean ethnically pure. You nuts.
-
Snipa
Github certianly is a poor single point of failure, and the more that we opt to integrate with it, the more dependant we become on it.
-
Snipa
Functionally, I don't see why we wouldn't go the kernel.org route if we /really/ wanted to go down this stream.
-
Snipa
Where the master repos are behind some super light weight system, everything else is done through sensible patches and patch management structures, most likely /not/ email knowing us, but something along those lines.
-
selsta
why make everything more inconvenient now just because maybe sometime in the future github could take down monero repo?
-
selsta
and even for this case we have backhub like I said so no data is at risk
-
ErCiccione[irc]
Accessibility should be taken in consideration. A lot of our contributors barely know how to use git.
-
Snipa
Again, not saying we should, but planning should be a consideration.
-
rehrar
one of the main reasons we wanted to stay in github is the 'discovery' factor. Everyone is on there. It's THE social media for devs nowadays.
-
Snipa
Disaster planning is part of running a business for a reason.
-
hyc
ErCiccione[irc]: eh? if they don't know how to use git, they have to learn
-
rehrar
although, realistically, how many people have contributed to Monero based on this discovery factor?
-
rehrar
I don't think we have any way of knowing.
-
ErCiccione[irc]
hyc: sure, but then you have to keep in consideration the drop of contributors, especially for the website. Github's UI is very convenient from that point of view, but gitlab's is good as well
-
ErCiccione[irc]
rehrar: i got some contributors to my GUI guide repository only by participating to the hactoberfest
-
ErCiccione[irc]
talking about last year or the one before
-
binaryFate
In my view anyone can step up and plan and execute on contingency plans. Even different people could propose/architect different solutions and get the infra ready already if they want to. Especially since we're discussing threat modelling and response, decentralization is key.
-
Snipa
^ It's git.
-
moneromooo
Maybe the website would not be banned if the safety protecting software were to be taken down.
-
binaryFate
For instance, core team is managing the backhub thing and paying for with donations. But anyone could also do their backup anywhere on their own, adding to resilience.
-
Inge-
and it might not be a bad thing if someone does so .. quietly :D
-
hyc
good point
-
hyc
but just having a backup of github repo + issue tracker is one thing
-
hyc
having an operational replacement if github shuts us down is another
-
rehrar
ultimately, I'm still for moving to something off github. Gitlab was kinda clunky. I've used Gogs before, and I know Gitea is just souped up Gogs, so I'd be down for either.
-
rehrar
but we'd need manpower and infra runners. Two things I'd not exactly say we're in excess of atm
-
selsta
gitea does not even use gitea for their repo yet
-
ErCiccione[irc]
hyc i think the only thing missing from the replacement would be the various CI. The rest would be ready to work (talking about the existing self hosted gitlab)
-
selsta
and setting up CI replacement is not crucial fo operations
-
selsta
for
-
rehrar
I know it sucks to have conversations like this over and over, but the world seems to be becoming increasingly hostile towards 'wrong-think'
-
rehrar
and I think it is prudent to come back to conversations like these as this gets worse
-
rehrar
which I suspect it will
-
fluffypony
well the thing is that we already have DR ready
-
binaryFate
IMO it's good to prepare alternatives, but I don't see why move away already. Agree with luigi1111 it's just inflicting inconvenience to ourselves. It's a way for the project to self-censor itself out of vague fear before someone needs to actively censor.
-
rehrar
if moving away is a pro-con analysis, and even if right now the cons outweigh the pros and so we don't move, the pros of moving may one day outweigh the cons, even just as the balance is tipped further and further by hostile takedowns
-
selsta
rehrar: we have plans in case github takes us down
-
rehrar
yes, but the github getting taken down is only one of the pros of moving. dsc outlined others, such as Tor contribution
-
fluffypony
I don't think we need to move, we tried that already and it didn't work - if we're FORCED to move that's different and we have multiple contingencies in place
-
fluffypony
rehrar: yes but the handful of additional pros don't outweigh the cons
-
fluffypony
ErCiccione has a whole write-up on the issues
-
moneromooo
Right. The moon base is almost in place.
-
rehrar
at present, I think I agree
-
fluffypony
and it wasn't JUST because of GitLab, it was other things
-
ErCiccione[irc]
rehrar: Github works with Tor afaik. not reliably, but it works
-
asymptotically
yes github works fine thru tor, both the webui and git+ssh push/pull
-
hyc
if you guys are satisfied that no changes need to be made at this time, fine with me
-
hyc
summarize these points in the issue and close it...
-
selsta
Snipa: what happens when someone runs rm -rf / on the self hosted gitlab runner?
-
Snipa
Runners are run as a sub-user, not root.
-
Snipa
Worst comes to worst, it nukes the user's local stuff, but all the config files are owned by root (In a proper setup), or you do Docker in Docker, then it doesn't matter.
-
Snipa
There's ways to mostly do it safely, there's always risks involved, but the GL runner tends to be pretty fail-safe. Also, you can protect the gl runner file if you get a higher version so people can't make MR's that change it, which then wouldn't run because they couldn't submit a MR that changes the build file.
-
gingeropolous
dunno bout this...2020-10-26 19:57:12.153 E Exception in main! PID file /home/user/wacky_work/save_pid.txt already exists and the PID therein is valid
-
xmr-pr
mj-xmr opened pull request #6937: Add RELINK_TARGETS and monero_add_target_no_relink
-
xmr-pr
-
selsta
Can an inbound peer be used as an outbound one?
-
Inge-
I just assumed that inbound = connection initated outside = port must be open, while outbound is your daemon initiating the request - and that both types of connections can work both ways for practical purposes
-
kayront
if by used as outbound you mean push stuff into it, then sure (since it works with incoming connections disabled)
-
kayront
if you mean having it connected to you as you are at the same time connected to it, in principle it seems not to make sense
-
kayront
by the way, i'm not getting any incoming connections over tor. it's been 10+ hours now. is this expected?
-
kayront
i passed --anonymous-inbound
-
Inge-
I mean both inbound and outbound can be used for downloading blocks and pushing transactions etc..
-
kayront
yeah
-
selsta
I have like 10+ inbound connections (I2P and Tor), but not a single outbound one
-
selsta
so my daemon complains "Lost all outbound connections to anonymity network - currently unable to send transaction(s)"
-
kayront
yes, that's become my new most seen message in the console too
-
kayront
in my case i only have outbound tor connections, nothing coming in
-
selsta
weird, opposite here :P
-
kayront
at the same time the tor daemon complains about failing to reach this or that [scrubbed], so it does seem to be an issue with tor in my case
-
xmr-pr
selsta opened issue #6938: tx-proxy I2P / Tor, no outbound connections (only inbound)
-
xmr-pr
-
Lyza
selsta I think that issue may overlap with this one, which I've been dealing with for a bit. a temporary solution is to add a couple of i2p / tor priority nodes.
monero-project/monero #6631
-
kayront
selsta
-
kayront
could you pm me your --anonymous-inbound line?
-
kayront
or paste here if you prefer
-
selsta
Lyza: do you have inbound also staying stable? but yes, your issue looks similar
-
selsta
kayront: I2P or Tor?
-
kayront
tor
-
Lyza
selsta yes I do. some of my inbound connections have lasted for as long as my daemon has been up (right now about 3 hours)
-
Lyza
otoh my longest lasting outbound i2p connection at the moment is just 180 seconds old