Kronovestan: added, the other ones, you sure about 104.243.35.17 ?

it is not DigitalOcean / OVH, which is normally used

also FYI, increasing out peers also increases the chance of connecting to an attacker node

added 104.243.35.17 too

.merges

^ would be ready for merges + v0.17.1.7 tag

luigi1111w: looks good to tag

done

selsta, appears the attacker is using another host I think

Got a second report about the IP so I added it

the .7 tag is used to test or publish,without having to wait for 7135?

7135 requires the majority of nodes to run 7130

so we can’t include it in .7, also it is still work in progress

hashes: paste.debian.net/1176663

Kronovestan: did you just see 104.243.35.17 getting blocked, or did you see it reporting +2 using sync_info?

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

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?

They have to get kicked a couple times before they are banned.

They will show up with "bans" command.

Alright, thanks. How to best watch the "kicking" then? Is there a special log category to best use?

It will display it

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.

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?

not sure if I follow

we will make this necessary after the next network upgrade

ah

selsta but why is 7131 in the release branch merged when 7130 is not merged?

?

It's supposed to be included in the next network upgrade, not in 0.17.1.7

7135 will be mandatory in the next network upgrade

both 7130 and 7131 are merged, not sure what you mean exactly

looked in the wrong place ¯\_(ツ)_/¯

Is it safe to add more data to the existing network messages? Will .7 nodes communicate normally with .6 nodes?

yes

I have been running it fine

it will just get ignored

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

scoobybejesus: my hashes match

selsta, I had seen 104.243.35.17 in my sync_info

everyone doing reproducible builds, please upload the hashes to gitian.sigs so that we can release v0.17.1.7 later today :)

so, trying to do my deterministic builds this morning

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?

I think the issue might be these 404 not found messages when downloading packages: pastebin.com/raw/xTM950s5

I'm guessing it worked for others because they already had the packages cached

Lyza: which command did you use?

selsta: ./gitian-build.py -j 3 --memory 3584 --detach-sign --no-commit --docker --build $GH_USER $VERSION

what did you set $VERSION ?

v0.17.1.7

hmm, that could be the case

we updated qt a while ago but looks like we only updated it in master branch

so it could be possible that we have it cached

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

do they get detected and kicked correctly?

With my daemon? Nothing gets kicked, as it seems - I have no messages at all in console output, except for that single stray ban

there is no message when a peer gets kicked

in log level 0

the test is to run without ban list and check status / sync_info if the +2 attack is working

Alright, so we misunderstood each other a few ours ago. Is there a way to modify log categories to see the kicks?

I misread probably. Kicking shows up in log level 1, bans in log level 0

It is easy for the attacker to add some rate limiting, e.g. only get kicked twice per IP.

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

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.

selsta should I open an issue on the build process then?

Lyza: will open a PR

./gitian-build.py -j 3 --memory 3584 --detach-sign --no-commit --docker --url github.com/selsta/monero --build $GH_USER qt-release

Lyza: can you check if ^ builds for you?

this will not be reproducible, but just curious if the error goes away

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

I have a lot such lines, so the bad nodes are active after all

Somehow ... satisfying to see them dropped so easily now.

for now :)

for now (with evil voice)

I found 2 numbers I grabbed at random from the log lines in "block.txt"

for now (with evil voice and fading echo ... echo ... echo ...)

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

so next attack will be on DNS to block all legit nodes, right?

Shouldn't be as easy as renting cloud servers and seed them with doctored Monero daemons, one would think

At least it's optional to use DNS list. I don't want another centralization point.

selsta that command gives me "error: pathspec 'qt-release' did not match any file(s) known to git."

you might have to do the first command step too

./gitian-build.py --setup $GH_USER $VERSION

add --url and replace version with qt-release

selsta pastebin.com/raw/D7dGiNgM

you have to add --url like in the previous comment

--url github.com/selsta/monero

damn I missed that part

selsa same result: pastebin.com/raw/FGdx3RZj

selsta *

first step appears to go okay, but tells me it needs to reboot. second step fails both before & after reboot

Use a different folder. md ../test && cd ../test && ./gitian-build.py --setup --docker --url github.com/selsta/monero Lyza qt-release

s/md/mkdir/

I'm seeing lot of difference in peers from a 17.1.7 synced node.. could that be public nodes updating after new version?

I meant difference in height

mfoolb: how do you see this?

sync_info

post the output

to paste.debian.net or so

looks fine, afaik it can take a bit until the height of peers update

ok.. I have some problem with gitian build

Could not download some packages, please run gbuild --upgrade

Do you not recognize your problem in the conversation above ?

iDunk: talking to me?

Yes. Same resolution.

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

iDunk: got to check the logs then..

Could be a node running in --no-sync. As long as the node is not lying about its height it is fine.

selsta: ok, thanks

iDunk: so this is not actual: github.com/monero-project/monero/tr…ster/contrib/gitian#gitian-building

I think it is.

./gitian-build.py --setup --docker $GH_USER $VERSION <-- this is the setup for docket I found there

Have you read the backlog and what selsta said ?

to add --url github.com/selsta/monero ?

running with --url will result in the wrong hashes. though it should still compile

selsta: running without --url is not working.. It's me doing something wrong? Should it build?

One of the sources seems offline

it worked for those that still had it cached

ok thanks

Should be fixed in the next version

Maybe we should skip right to .8 with 7140 if gitian is unbuildable for newcomers.

I already spent multiple hours doing GUI builds :/ Would prefer not.

If hyc also does builds we would have ti

them confirmed by 4 people

I'll PR hashes soon.

what's up?

qttools-opensource-src-5.7.1.tar.gz receive a 404 while preparing for gitian build

ugh

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

yes, I read you before and I humbly agree

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.

you can still sha256sum the image

but you can't build if OS' repo don't know or don't want to check availability of needed packages

Does the original repo still have the hash, just not the actual package ?

my last build failed because linux-image-generic was unavailable

which is a stupid reason to fail in the first place

I commented out the repo check to get past that

It's a source tarball that's been removed.

but being at the mercy of these repo prociders is ... fragile

providers

moneromooo: No package and no hash in the md5sums.txt file on repo

And does building with the new OS packages get you the exact same resulting monero binaries ?

OS packages have nothing to do with this.

A tarball is missing somewhere on the internet.

Surely it depends what the tarball is for. ie, if it's gcc and the new gcc happens to have a new optimizer.

Anyway, it's not like I biuld those so I'll leave those who do decide :)

let

nice

moneromooo: If you can see pastebin :54:26 < Lyza> I think the issue might be these 404 not found messages when downloading packages: pastebin.com/raw/xTM950s5

moneromooo: pastebin.com/aJXnQ69D

Sure, GCC was an extreme example to make the point.

I guess it would work if the people building and PRing signatures don't use the prepared deps.

Anway, "Obimooo Kenobi: Merge them in pairs, Luke!"

perhaps we should be getting qtbase from code.qt.io or its github mirror instead

why were we using some random site in Brazil in the first place?

Oh I see, 5.7.1 is too old, it got removed from code.qt.io

and from the random brazilian site too :)

why don't we update to a recent version?

selsta just did.

5.15.1 is already in master, but release PR was never done.

ok

Until toda.

y

btw it's still on github github.com/qt/qtbase/releases/tag/v5.7.1

yoda ?

I just downloaded the github copy, hash doesn't match the one we're using

the github source is auto generated by github

source archive

right

monero-project/monero #7140 should solve it

oh :) didn't read backlog

ok, so updated qt needs to go into next release and then no problem

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 paste.debian.net/plain/1176744

huh haven't seen that before. I guess the set of trusted root certs is out of date

FF doesn't throw any warnings about the cert so, yeah maybe

LOL their server cert has a typo

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

OU = nformation Technology Services - missing first "I"

oopsie

"L = Chapel HIll" capital I

found it there :D

lol

lol

the issuer cert that's missing is InCommon

have a reference here uit.stanford.edu/service/ssl/chain

will try downloading it from that link

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.

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.

Lyza: yes, if you grab the Incommon cert that was linked from that Stanford page, curl will work

but it has to be installed into the docker image each time, how annoying

.7 should fix it for a short time.

thx hyc

This is great context, thanks selsta

<moneromooo ".7 should fix it for a short tim"> Great! But still recommend ban-list?

Lyza: you can bypass this problem by manually downloading the file yourself

move it into ~gitianuser/builder/cache/common

put the sha256sum output into ~gitianuser/builder/cache/common/download-stamps

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

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

using .stamp_fetched_xxxxx

ahhh I didn't put the sha256 anywhere okay

look at the other ,stamp_fetched* files in download-stamps

.stamp_fetched...

should be .stamp_fetched-native_cdrkit-cdrkit-1.1.11.tar.bz2.hash

*fingers crossed*

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

prolly about all the patience I have for it for now but thx y'all for the help

0.17.1.7 paste.debian.net/1176777

sethsimmons: yes, or the DNS blocklist in 7139 if auto update is required.

I will maintain that one, selsta will maintain the file one. So you can choose whose list you like :)

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