02:26:58 <selsta> Kronovestan: added, the other ones, you sure about 104.243.35.17 ?
02:27:06 <selsta> it is not DigitalOcean / OVH, which is normally used
02:27:51 <selsta> also FYI, increasing out peers also increases the chance of connecting to an attacker node
02:45:18 <selsta> added 104.243.35.17 too
03:49:58 <selsta> .merges
03:49:58 -xmr-pr- 6495 7123 7124 7127 7128 7130 7131
03:50:20 <selsta> ^ would be ready for merges + v0.17.1.7 tag
04:09:16 <selsta> luigi1111w: looks good to tag
04:11:01 <luigi1111w> done
05:00:40 <Kronovestan> selsta, appears the attacker is using another host I think
05:01:11 <selsta> Got a second report about the IP so I added it
05:04:13 <cvg8> the .7 tag is used to test or publish,without having to wait  for 7135?
05:07:14 <selsta> 7135 requires the majority of nodes to run 7130
05:07:40 <selsta> so we can’t include it in .7, also it is still work in progress
06:08:32 <scoobybejesus> hashes: https://paste.debian.net/1176663/
06:44:20 <selsta> Kronovestan: did you just see 104.243.35.17 getting blocked, or did you see it reporting +2 using sync_info?
06:52:01 <selsta> it also got auto banned from my nodes, so not clear what they did. will keep it on the block list I guess, they can reach out if it was a mistake
08:56:18 <rbrunner> I am testing .7 as tagged a few hours ago, but I am a little out of the loop: Do recognized-as-bad peers get listed if I use the interactive "bans" command?
08:56:56 <selsta> They have to get kicked a couple times before they are banned.
08:57:05 <selsta> They will show up with "bans" command.
09:10:31 <rbrunner> Alright, thanks. How to best watch the "kicking" then? Is there a special log category to best use?
09:15:32 <selsta> It will display it
09:26:56 <rbrunner> With the standard log level 0 already then, right? Ok. Then I guess it's just all quiet on that front right now, my daemon is sitting there silently, with over 70 out peers.
09:29:09 <M5M400> selsta | 7135 requires the majority of nodes to run 7130 <- is that wise? given that a certain someone is spinning up nodes on da daily basis?
09:30:10 <selsta> not sure if I follow
09:30:51 <selsta> we will make this necessary after the next network upgrade
09:42:25 <M5M400> ah
09:46:41 <sech1> selsta but why is 7131 in the release branch merged when 7130 is not merged?
09:47:10 <selsta> ?
09:47:27 <sech1> It's supposed to be included in the next network upgrade, not in 0.17.1.7
09:47:56 <selsta> 7135 will be mandatory in the next network upgrade
09:48:35 <selsta> both 7130 and 7131 are merged, not sure what you mean exactly
09:49:12 <sech1> looked in the wrong place ¯\_(ツ)_/¯
09:49:41 <sech1> Is it safe to add more data to the existing network messages? Will .7 nodes communicate normally with .6 nodes?
09:49:48 <selsta> yes
09:50:03 <selsta> I have been running it fine
09:52:28 <selsta> it will just get ignored
09:53:29 <selsta> and once we include 7135 in a release (and the majority on nodes updated) it should be possible to run with --early-pow-sanity-check
10:08:14 <selsta> scoobybejesus: my hashes match
11:04:18 <Kronovestan> selsta, I had seen 104.243.35.17 in my sync_info
11:19:51 <selsta> everyone doing reproducible builds, please upload the hashes to gitian.sigs so that we can release v0.17.1.7 later today :)
12:45:20 -xmr-pr- codesoap opened pull request #7137: readline_buffer: Avoid consecutive duplicates in the history
12:45:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7137
14:21:33 <iDunk> https://paste.debian.net/hidden/738aed03/
14:30:20 -xmr-pr- moneromooo-monero opened pull request #7139: Optional DNS based blocklist
14:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7139
14:30:21 -xmr-pr- moneromooo-monero opened pull request #7138: Optional DNS based blocklist
14:30:21 -xmr-pr- > https://github.com/monero-project/monero/pull/7138
14:45:26 <Lyza> so, trying to do my deterministic builds this morning
14:45:39 <Lyza> https://paste.debian.net/1176703/
14:46:22 <tevador> I've been running v0.17.1.7 for a couple hours with over 150 peers and my banlist is still empty. Is that expected?
14:54:26 <Lyza> I think the issue might be these 404 not found messages when downloading packages: https://pastebin.com/raw/xTM950s5
14:55:14 <Lyza> I'm guessing it worked for others because they already had the packages cached
14:55:57 <selsta> Lyza: which command did you use?
14:56:39 <Lyza> selsta: ./gitian-build.py -j 3 --memory 3584 --detach-sign --no-commit --docker --build $GH_USER $VERSION
14:57:08 <selsta> what did you set $VERSION ?
14:57:21 <Lyza> v0.17.1.7
14:58:26 <selsta> hmm, that could be the case
14:59:12 <selsta> we updated qt a while ago but looks like we only updated it in master branch
15:00:07 <selsta> so it could be possible that we have it cached
15:01:13 <rbrunner> I am running .7 for six hours now, with 200 out peers, with only a single ban, which makes me think: I as an attacker would stop attacks until .7 is out; otherwise we could test too easy
15:01:57 <selsta> do they get detected and kicked correctly?
15:02:51 <rbrunner> With my daemon? Nothing gets kicked, as it seems - I have no messages at all in console output, except for that single stray ban
15:03:08 <selsta> there is no message when a peer gets kicked
15:03:25 <selsta> in log level 0
15:03:34 <selsta> the test is to run without ban list and check status / sync_info if the +2 attack is working
15:04:11 <rbrunner> Alright, so we misunderstood each other a few ours ago. Is there a way to modify log categories to see the kicks?
15:04:47 <selsta> I misread probably. Kicking shows up in log level 1, bans in log level 0
15:05:02 <selsta> It is easy for the attacker to add some rate limiting, e.g. only get kicked twice per IP.
15:05:35 <rbrunner> Yeah, but too many other things show up with log level 1 :) I don't use the ban list, btw, and I am fully synced for those 6 hours
15:06:22 <selsta> We can tune this for the next release. Some things don’t happen by accident / slow network, so for some things it should be possible to ban instantly and not after a couple times.
15:06:29 <Lyza> selsta should I open an issue on the build process then?
15:07:36 <selsta> Lyza: will open a PR
15:10:58 <selsta> ./gitian-build.py -j 3 --memory 3584 --detach-sign --no-commit --docker --url https://github.com/selsta/monero --build $GH_USER qt-release
15:11:04 <selsta> Lyza: can you check if ^ builds for you?
15:11:23 <selsta> this will not be reproducible, but just curious if the error goes away
15:15:20 -xmr-pr- selsta opened pull request #7140: [release-v0.17] Depends: Bump qt to 5.15.1
15:15:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7140
15:16:04 <rbrunner> Got it: With "set_log +net.cn:INFO" in the daemon console you can see a red line logged if a daemon is dropped because it claims a wrong height
15:16:56 <rbrunner> I have a lot such lines, so the bad nodes are active after all
15:20:14 <rbrunner> Somehow ... satisfying to see them dropped so easily now.
15:20:52 <selsta> for now :)
15:21:30 <sech1> for now (with evil voice)
15:21:38 <rbrunner> I found 2 numbers I grabbed at random from the log lines in "block.txt"
15:22:26 <rbrunner> for now (with evil voice and fading echo ... echo ... echo ...)
15:22:41 <selsta> with v0.17.1.8 and DNS based block list the issue should be mostly mitigated even if he still finds edge cases to exploit
15:27:11 <sech1> so next attack will be on DNS to block all legit nodes, right?
15:28:53 <rbrunner> Shouldn't be as easy as renting cloud servers and seed them with doctored Monero daemons, one would think
15:31:18 <sech1> At least it's optional to use DNS list. I don't want another centralization point.
15:32:08 <Lyza> selsta that command gives me "error: pathspec 'qt-release' did not match any file(s) known to git."
15:37:55 <selsta> you might have to do the first command step too
15:38:27 <selsta> ./gitian-build.py --setup $GH_USER $VERSION
15:38:39 <selsta> add --url and replace version with qt-release
15:51:10 <Lyza> selsta https://pastebin.com/raw/D7dGiNgM
15:51:48 <selsta> you have to add --url like in the previous comment
15:52:07 <selsta> --url https://github.com/selsta/monero
15:52:09 <Lyza> damn I missed that part
16:22:36 <Lyza> selsa same result: https://pastebin.com/raw/FGdx3RZj
16:22:40 <Lyza> selsta *
16:23:36 <Lyza> first step appears to go okay, but tells me it needs to reboot. second step fails both before & after reboot
16:28:27 <iDunk> Use a different folder. md ../test && cd ../test &&  ./gitian-build.py --setup --docker --url https://github.com/selsta/monero Lyza qt-release
16:29:41 <iDunk> s/md/mkdir/
16:29:45 <mfoolb> I'm seeing lot of difference in peers from a 17.1.7 synced node.. could that be public nodes updating after new version?
16:29:48 <mfoolb> I meant difference in height
16:31:45 <selsta> mfoolb: how do you see this?
16:31:55 <mfoolb> sync_info
16:32:03 <selsta> post the output
16:32:09 <selsta> to paste.debian.net or so
16:33:46 <mfoolb> https://paste.debian.net/1176736
16:34:14 <selsta> looks fine, afaik it can take a bit until the height of peers update
16:34:46 <mfoolb> ok.. I have some problem with gitian build
16:35:23 <mfoolb> Could not download some packages, please run gbuild --upgrade
16:35:50 <iDunk> Do you not recognize your problem in the conversation above ?
16:36:46 <mfoolb> iDunk: talking to me?
16:37:02 <iDunk> Yes. Same resolution.
16:37:53 <mfoolb> selsta: after 15m this one is still locked at low height 75.139.205.63:18080       d7f83402f7990756  normal            0         2249685  0 kB/s, 0 blocks / 0 MB queued
16:38:16 <mfoolb> iDunk: got to check the logs then..
16:38:45 <selsta> Could be a node running in --no-sync. As long as the node is not lying about its height it is fine.
16:39:20 <mfoolb> selsta: ok, thanks
16:42:56 <mfoolb> iDunk: so this is not actual: https://github.com/monero-project/monero/tree/master/contrib/gitian#gitian-building
16:43:44 <iDunk> I think it is.
16:45:48 <mfoolb> ./gitian-build.py --setup --docker $GH_USER $VERSION <-- this is the setup for docket I found there
16:46:13 <iDunk> Have you read the backlog and what selsta said ?
16:47:18 <mfoolb> to add --url https://github.com/selsta/monero ?
16:48:06 <selsta> running with --url will result in the wrong hashes. though it should still compile
16:48:56 <mfoolb> selsta: running without --url is not working.. It's me doing something wrong? Should it build?
16:49:39 <selsta> One of the sources seems offline
16:49:53 <selsta> it worked for those that still had it cached
16:49:59 <mfoolb> ok thanks
16:50:13 <selsta> Should be fixed in the next version
16:52:36 <iDunk> Maybe we should skip right to .8 with 7140 if gitian is unbuildable for newcomers.
16:54:28 <selsta> I already spent multiple hours doing GUI builds :/ Would prefer not.
16:57:56 <selsta> If hyc also does builds we would have ti
16:58:01 <selsta> them confirmed by 4 people
16:58:43 <iDunk> I'll PR hashes soon.
17:03:37 <hyc> what's up?
17:04:50 <mfoolb> qttools-opensource-src-5.7.1.tar.gz receive a 404 while preparing for gitian build
17:05:14 <hyc> ugh
17:06:03 <hyc> as I mentioned before, we ought to just be creating a frozen docker image of all the dependencies instead of downloading all of them at build time
17:06:50 <mfoolb> yes, I read you before and I humbly agree
17:07:32 <moneromooo> If you pull all your deps from what the monero team prepared for you, if opens the door to the monero team to supply crafted deps. That doesn't happen if you pull from the OS' package repo.
17:08:39 <hyc> you can still sha256sum the image
17:08:56 <mfoolb> but you can't build if OS' repo don't know or don't want to check availability of needed packages
17:09:05 <moneromooo> Does the original repo still have the hash, just not the actual package ?
17:10:03 <hyc> my last build failed because linux-image-generic was unavailable
17:10:09 <hyc> which is a stupid reason to fail in the first place
17:10:23 <hyc> I commented out the repo check to get past that
17:10:29 <iDunk> It's a source tarball that's been removed.
17:11:00 <hyc> but being at the mercy of these repo prociders is ... fragile
17:11:04 <hyc> providers
17:11:21 <mfoolb> moneromooo: No package and no hash in the md5sums.txt file on repo
17:12:23 <moneromooo> And does building with the new OS packages get you the exact same resulting monero binaries ?
17:12:38 * moneromooo guessing "it depends"
17:12:56 <iDunk> OS packages have nothing to do with this.
17:13:14 <iDunk> A tarball is missing somewhere on the internet.
17:14:02 <moneromooo> Surely it depends what the tarball is for. ie, if it's gcc and the new gcc happens to have a new optimizer.
17:15:17 <moneromooo> Anyway, it's not like I biuld those so I'll leave those who do decide :)
17:15:20 -xmr-pr- moneromooo-monero opened pull request #7142: daemon: the ban command can now load IPs from a file (ban @filename)
17:15:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7142
17:15:20 -xmr-pr- moneromooo-monero opened pull request #7141: daemon: the ban command can now load IPs from a file (ban @filename)
17:15:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7141
17:15:25 <moneromooo> let
17:15:39 <Lyza> nice
17:16:06 <iDunk> moneromooo: If you can see pastebin  :54:26 < Lyza> I think the issue might be these 404 not found messages when downloading packages: https://pastebin.com/raw/xTM950s5
17:16:51 <mfoolb> moneromooo: https://pastebin.com/aJXnQ69D
17:17:29 <moneromooo> Sure, GCC was an extreme example to make the point.
17:18:43 <moneromooo> I guess it would work if the people building and PRing signatures don't use the prepared deps.
17:19:27 <iDunk> Anway, "Obimooo Kenobi: Merge them in pairs, Luke!"
17:23:58 <hyc> perhaps we should be getting qtbase from code.qt.io or its github mirror instead
17:24:17 <hyc> why were we using some random site in Brazil in the first place?
17:24:56 <hyc> Oh I see, 5.7.1 is too old, it got removed from code.qt.io
17:25:23 <mfoolb> and from the random brazilian site too :)
17:25:41 <hyc> why don't we update to a recent version?
17:25:52 <moneromooo> selsta just did.
17:25:54 <iDunk> 5.15.1 is already in master, but release PR was never done.
17:25:58 <hyc> ok
17:26:01 <iDunk> Until toda.
17:26:04 <iDunk> y
17:26:06 <hyc> btw it's still on github https://github.com/qt/qtbase/releases/tag/v5.7.1
17:26:09 <moneromooo> yoda ?
17:27:34 <hyc> I just downloaded the github copy, hash doesn't match the one we're using
17:29:42 <selsta> the github source is auto generated by github
17:29:55 <selsta> source archive
17:30:03 <hyc> right
17:30:17 <selsta> https://github.com/monero-project/monero/pull/7140 should solve it
17:30:37 <selsta> oh :) didn't read backlog
17:32:56 <hyc> ok,  so updated qt needs to go into next release and then no problem
17:37:51 <Lyza> selsta okay I got about as far as last time but it still says it can't get some of the packages. the only specific package download error I see is https://paste.debian.net/plain/1176744
17:38:45 <hyc> huh haven't seen that before. I guess the set of trusted root certs is out of date
17:39:43 <Lyza> FF doesn't throw any warnings about the cert so, yeah maybe
17:45:01 <hyc> LOL their server cert has a typo
17:45:02 <hyc> C = US, postalCode = 27514, ST = North Carolina, L = Chapel HIll, street = 153A Country Club Road, O = University of North Carolina at Chapel Hill, OU = nformation Technology Services, CN = distro.ibiblio.org
17:45:29 <hyc> OU = nformation Technology Services - missing first "I"
17:46:22 <Lyza> oopsie
17:46:39 <sech1> "L = Chapel HIll" capital I
17:46:50 <sech1> found it there :D
17:47:34 <Lyza> lol
17:47:34 <hyc> lol
17:47:50 <hyc> the issuer cert that's missing is InCommon
17:47:57 <hyc> have a reference here https://uit.stanford.edu/service/ssl/chain
17:48:12 <hyc> will try downloading it from that link
17:51:32 <sethsimmons> So is .7 supposed to fix +2 issue natively without ban-list, or .8, or neither? Have several people waiting on a non-ban list fix I’d like to keep in the loop, as well as update my blog post.
17:52:05 <sethsimmons> I’ll comb through the PRs since I released that and see what is important to add as mitigations unless someone has a list handy as well.
17:52:13 <hyc> Lyza: yes, if you grab the Incommon cert that was linked from that Stanford page, curl will work
17:52:42 <hyc> but it has to be installed into the docker image each time, how annoying
17:54:43 <moneromooo> .7 should fix it for a short time.
17:55:35 <Lyza> thx hyc
17:58:26 <sethsimmons> https://reddit.com/r/Monero/comments/kc88cu/_/gfosz1h/?context=1
17:58:26 <sethsimmons> This is great context, thanks selsta
17:58:42 <sethsimmons> <moneromooo ".7 should fix it for a short tim"> Great! But still recommend ban-list?
18:11:44 <hyc> Lyza: you can bypass this problem by manually downloading the file yourself
18:11:56 <hyc> move it into ~gitianuser/builder/cache/common
18:12:18 <hyc> put the sha256sum output into ~gitianuser/builder/cache/common/download-stamps
18:12:21 <Lyza> I did try that hyc and it was still complaining about not being able to get something, though I dind't see any more errors. let me try again
18:12:40 <Lyza> I was able to add the cert to my base system but Ig it needs to be added to the docker image and I'm not sure about how to do that one
18:12:45 <hyc> using .stamp_fetched_xxxxx
18:12:55 <Lyza> ahhh I didn't put the sha256 anywhere okay
18:13:18 <hyc> look at the other ,stamp_fetched* files in download-stamps
18:13:25 <hyc> .stamp_fetched...
18:14:16 <hyc> should be .stamp_fetched-native_cdrkit-cdrkit-1.1.11.tar.bz2.hash
18:17:55 <Lyza> *fingers crossed*
18:35:27 <Lyza> well, I might be doing something wrong but I double checked the file names and locations and all and I keep getting the same error
18:36:31 <Lyza> prolly about all the patience I have for it for now but thx y'all for the help
21:18:17 <hyc> 0.17.1.7 http://paste.debian.net/1176777/
21:36:12 <moneromooo> sethsimmons: yes, or the DNS blocklist in 7139 if auto update is required.
21:36:42 <moneromooo> I will maintain that one, selsta will maintain the file one. So you can choose whose list you like :)
21:52:33 <netrik182[m]> why were we using some random site in Brazil in the first place? <-- not completely random. USP is the biggest Uni in SA but still
23:30:20 -xmr-pr- moneromooo-monero opened pull request #7146: p2p: remove peers from grey and anchors lists when blocked
23:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7146
23:30:20 -xmr-pr- moneromooo-monero opened pull request #7145: p2p: remove peers from grey and anchors lists when blocked
23:30:20 -xmr-pr- > https://github.com/monero-project/monero/pull/7145
23:30:21 -xmr-pr- moneromooo-monero opened pull request #7144: p2p: ignore incoming peer list entries when we have them blocked
23:30:21 -xmr-pr- > https://github.com/monero-project/monero/pull/7144
23:30:22 -xmr-pr- moneromooo-monero opened pull request #7143: p2p: ignore incoming peer list entries when we have them blocked
23:30:22 -xmr-pr- > https://github.com/monero-project/monero/pull/7143