I can tell you why you can't stop the 'spam'. You are thinking in cult doctrine. If it was real spam, and I was selling Viagra for example - you could easily ban keywords and urls. Instead, stop being a sheep, think like a cult leader. Recoginse that this 'spam' is just some bullshit that you tell to the sheep.

When you do that, solution will present itself. Observe. 'spam' -> 'FUK talks bad things about Monero on our IRC' (Don't say that out loud obviously, that will get you excommunicated) Solution? Get off-the-shelf sentiment analyser, detect anyone who 'talks bad things about Monero' and ban them.

Word of guys running Monero community should be BELIEVED. Why would anyone that stole money and laughed at the losers that took the bait ever have a reason to lie to you? www.reddit.com/r/Monero/comments/6d6okb/what_fluffypony_just_did_is_not_ok/

v0.17.2.0 binaries are now available at getmonero.org, great job everyone

I need testers to check how the content of the sources tarball put on the website can be automatically checked when I commit a new release to the website (just like the hashes are currently checked withhttps://github.com/selsta/monero-site/blob/715eab2cd10c770f6f814e40d0885068392e03a3/.github/workflows/hashes.yaml)

the job should be able to recreate the tarball from the github repo in the same way as I do, and then compare content to check there are no differences

but weirdly selsta has one line that is changing in one file when he's reproducing the exact same workflow. I'd like to know if there can be even more differences (and if so where they are coming from)

If you want to help can you run this paste.debian.net/1193199 and report the result of the "diff" commands at the end

I expect the diff results to be empty (directories to be exactly the same)

Connecting to dlsrc.getmonero.org (dlsrc.getmonero.org)|172.67.14.95|:443... connected.

HTTP request sent, awaiting response... 403 Forbidden

For dlsrc.getmonero.org/gui/monero-gui-source-v0.17.2.0.tar.bz2

works for me right now

try downloads.getmonero.org/gui/monero-gui-source-v0.17.2.0.tar.bz2 ?

Works.

That one is 157.185.165.36 though, different IP.

dlsrc works here too

it's CDN

Maybe they don't like tor.

yes possible that you're hitting cloudflare and they didn't like you

I don't like cloudflare so fair game.

:)

captchaflare

People who say they don't hate tor but make it so easy for others to block it.

afaik dlsrc is not a cdn

dlsrc -> CloudFlare

I think that's the direct but still through CF

downloads -> dlsrc -> CloudFlare

whois says cloudflare here.

the one that crack me up the most is exchanges/web wallets that use CF .. yes, very sensible idea

kayront: I don't think it's any different from running an F5 WAF in front of it

or a virtual appliance WAF on AWS

the WAF could be compromised in subtle ways

Do you give F5 WAF your SSL keys too ?

moneromooo: yes, otherwise it's a pretty useless WAF

fluffypony: i get your point, but i think it is, though. people have a valid expectation that they are connecting e2e to a certain server from a certain organization, and instead they end up connecting to an american megacorp and probably without realizing

A third party you have to give your keys to for security is also pretty useless by definition.

ofc you could make the same point about AWS, but in theory is seems easier to exfiltrate from CF instead of AWS. although probably both are happening pretty regularly :D

was about to make the AWS argument lol

you're either leveraging CF or similar for scale, or you're leveraging AWS / Azure / similar

no, i agree. i prefer to self-host as a matter of pricniple because of that & more

Sounds a lot like "this is not perfect either so we might as well go for the shittest".

might be a bit more expensive, but my dignity remains

lo

At least if people use cloud servers the enemy has to pwn lots of different places to slurp 50% of the whole internet.

moneromooo: or just pwn one datacenter :-P

Not just one (if they're actually different from NSA, which I hav emy doubts about).

Are you claiming all hosting companies are basically brands of a single one ?

something tells me AWS has tools at the dom0/hypervisor to read process tables of guest OSes, dump process memory, exfiltrate passwords, and all that. it only makes sense

Should have gone for the DNS root servers and get 99%.

kayront: yeah pretty sure they do

otoh if it's physical tin it's not like the DC does a good job of protecting cages

something also tells me that data gets fed directly to our favorite 3 letter agencies

unless you have a really good relationship with them and you put your own cage in, but nowadays that's infrequent

lol

i'd liek to put the FATF in a cage

and throw away the key

anyway, I think that it's largely a losing battle on clearnet - if you want e2e straight to the server you need an overlay network like Tor or i2p

Except if all the nodes are MITMed by cloudflare.

coming up next: CF Tor Onion Accelerator™

something pretty cool that never got much traction is onioncat. do you guys know it?

the VPN thing?

Never heard, but it evokes interesting images.

haha moneromooo

yeah fluffypony, in some sense

aiui it's a VPN overlay for Tor

quick reading the readme tells me they never found a good solution for V3 addresses, whcih is a shame

the length of v2 addrs used to match perfectly for the scheme, not so much anymore.. manual configuration for every single host kind of (but not entirely, depending on use case) defeats the purpose

ah yeah

i used to daydream how cool it could be to offer onioncat-only hosting for people at home - the main reason i wouldn't rent zones/jails/containers/vms right now is all the liability that could bring, not unlike running a tor exit in a way .. but if everything (and I mean everything, like onioncat pkg servers, etc) was going over tor, then yolo

xmr accepted there ofc

:p

nice

binaryFate: empty diffs after changing dlsrc to downloads.

moneromooo: is the hash reproducible?

Of what excatly ?

I don't see an obvious hash displayed.

ok good

I mean do you get the same source tarball hash as on getmonero.org

you could set up trustworthy hosting with AMD Epyc servers. hardware-encrypted VM RAM that the host can't decrypt

unfortunately git-archive is not deterministic apparently because it embeds the PID into the archive

moneromooo linux or macos?

doubt that mooo would use macos :D

right, I retract that question ^^

It did not create compressed tarballs here, so does not apply.

it shoud have, and then uncompressed them

bzip2 foo.tar sounds inherently non deterministic since small changes in bzip2 would cause different output (ie, slightly better compression).

Right, I see bunzip2 in the script. I'll re-run and not delete.

mistery is that selsta does the exact same workflow on macos and one line in one file ends up changed in his tarballs

Is that... a puzzling fog ?

?

Nevermind. Mistery.

I have to google that sort of stuff to check if it's not an expression with a specific meaning that I don't know

The hashes are different.

yes, but the diff is empty?

Yes.

hyc: I did not know about that. looks pretty cool on first read. what guarantees do we have in terms of auditability (that it does what it says it does), or, how is it different than SGX or a hw RNG in terms of trusting its magic?

ok so that workflow can be used to check tarball is ok. Except for the mistery.

kayront: no guarantees that there is no NSA-sponsored backdoor. but AMD has a pretty good track record on this feature.

it is quite different from SGX. Every VM has its own AES key, handled internally by the CPU itself, never visible to user code

selsta: what is the line/file that's different ?

moneromooo line 35 of cmake/Version.cmake

the $Format:$ becomes an empty string

Do other $Format:$ in other files (if you add them) also do the same ?

can try

I don't see what in that workflow can evaluate anything

maybe you have some local hooks interacting on git-archive

Sounds like CVS, but... should be long dead.

15:56 <+moneromooo> Do other $Format:$ in other files (if you add them) also do the same ? <-- yes

try to set Format="foo" in your shell and redo?

Next step is to add xterm -e sh between each step, so you can grep to see when it changes :)

Maybe "$Version:$" would also cause the culprit to identify itself.

don't have xterm here

Just sh will do, if it's not redirected.

Or any windowed tty program.

../git-archive-all.sh: line 214: [: -eq: unary operator expected

not sure if that is related

If you replace with "$Format:%H$", do you get a hash instead of empty ?

If yes, I think the fix might be to add a .gitattributes file in the monero root directory with "* -export-subst" in it.

(alternatively, check your global git settings for export-subst)

no, it just also is gone

no hash

Including the %H ?

yes

hmm wait

Release available -> reddit.com/r/Monero/comments/mor649…li_gui_v01720_oxygen_orion_released

Could try $Format:%Credfoo%Creset$

If it doesn't display foo in red, then it's not export-subst for sure.

ok so git-archive-all undoes my changes

might have to commit them

15:56 <+moneromooo> Do other $Format:$ in other files (if you add them) also do the same ? <-- after commiting the changes, no

I added it to the readme and it stayed there

that's... weird

Do you have a .gitattributes file in ~ ?

no

Or wherever you might have user or system config

Will you HODL XMR or dump it for Tari when it comes out? Will others?

congrats on the synchronous CLI and GUI releases y'all!