Is there a solution for this? I cannot test myself what are the hops the requests goes through

damn temporary win8 brick

the linux64 URL 302s to this: dlsrc.getmonero.org/gui/monero-gui-linux-x64-v0.16.0.2.tar.bz2

^ fluffypony etc.

which in turn 301s to this: dlsrc.getmonero.org/gui/monero-gui-linux-x64-v0.16.0.2.tar.bz2

which then 200s

So it looks like the first redirect is HTTP for some reason, which is not good

thanks sarang :)

ping pigeons too

np

tks sarang

we'll have to check the nginx file to see how it redirects

Would there be any legitimate reason for this setup?

yes

it's wrong, but it's because updates.getmonero.org didn't support TLS

moneromooo: am I correct in saying that the auto-updater can now handle HTTPS?

ah

because then we can just force TLS

Yeah

Wouldn't be dangerous if everyone checks hashes and signatures

but MITM is no good

Could you at least force HTTPS for those links, and if needed use HTTP for the updater since it always checks signatures?

So at least an HTTP-routed updater would fail secure

Yeah but that's a big "if" :)

* That's a big "if" :)

HTTPS for links and _maybe_ HTTP for updater (but ideally not) would result in everyone failing secure (unless they manually do the HTTP link)

sarang: yes - that's a workaround if we still need to support HTTP

(I was just joking about "if everyone checks hashes", my message could have been relayed with a delay)

ErCiccione[m]: yeah, relying on hash and signature checks to avoid MITM seems like a bad idea

It does.

:D

Yep 🙂 Trusting people to do what's best for them? what could go wrong?

moneromooo: it does as in we can dump HTTP?

Yes.

ok cool

Cool

ErCiccione[m]: checking hashes and signatures is a bit of a PITA, though important

Best to provide some layers of protection for people who don't

Even though it's not possible to remove all risk

Just make sure you inlcude a cipher suite epee+openssl can use.

MD5+DES, got it

Who are you and what have you done with sarang ?

True, but i'm pleasantly surprised by the amount of people who actually check monero hashes. Maybe the website hack scared the most tech savy in the communityh

Check hashes, or hashes+signatures?

ok I've flipped on HTTPS everywhere for the whole of getmonero.org

and enabled HSTS

Many seem to at least check hashes, for what i noticed at least

and requested we go into the HSTS preload list

fluffypony: so the redirect should be gone? (will test)

so if anything breaks we'll know in the coming weeks that we're relying on HTTP for something

sarang: no not yet

we're fixing that too

That's a relative "many" tho

ah ok

Please let us know when that can be tested

ErCiccione[m]: checking only hashes doesn't do much of anything

And I don't want people to think it does more than it actually does

It's still something tho. It allowed us to notice we were showing wrong hashes in the downloads page recently

fair enough

Sure, but that was lucky

A more clever/capable attacker would have changed those too

Oh, you mean the switched hashes

yes

I think the download page language on signature verification should be much stronger, FWIW

To say that the only way to guarantee the binaries you have are those intended by the maintainers, you need to do both steps

"Your hardware might be pwned anyway, don't bother"

and that if you also wish to check that the maintainers honestly compiled the right code, you should do repro builds

moneromooo: :(

OK. Paranoid enough, but not too much.

Well, I think it should be more clear about what steps mitigate what risks

Checking hashes could be just asking the attacker "hey attacker, are you an attacker?" "um, no..."

Well, I get the idea, but if you claim you might get the wrong hahes to begin with, then you might get the wrong pubkey to begin with too. So you'd need to check the GPG sig in git for pony's key, and...

But sure, explaining what is what is good.

Yeah, and the real risk is a malicious binary, which has happened

Those two steps eliminate that risk

Problem solved

People worried about other risks can/should take extra steps

Not everyone cares about the repro build, and that's fine

But people who do care can (and do) run it

ok we've solved it, we're rolling it out for all the URLs, should be done in a few mins

Nice, that was fast

Probably worth noting in that issue why it was set up the way it was

(once it's fixed, that is)

ok all fixed

testing

pigeons did all the effort

all I did was clear the cache a bunch

no change yet

probably still a caching issue?

I'm getting a 302 to the http loation

oh hmmm

something still cached

lemme fix

unless `curl` is caching locally

nope, tried on a different machine

oh I rushed it sorry

pigeons is still busy

my bad

got it

yay all works

Confirmed!

party emoji!

Someone want to note this on the issue?

The original reasoning would be good too

I'm doing it now

cool

I'll confirm the test after you comment

in case that's helpful

Thanks pony and pigeons. I have a comment ready, but go for it :)

:D

Has there been any movement on removing analytics?

It was brought up a while ago

aren't they already gone?

Issue: monero-project/monero-site #978

asymptotically: analytics are not working but the JS code is still on the website

Personally, i'm fine with remove all JS and use only server logs for anamlytics

*removing

access_logs /dev/null; @ nginx ? :P

OK, anything that would need to be done before just making a PR that nukes the JS code?

I would prefer to have analytics working before deleting all JS. Doesn't really change anything practically, but at least keeps people's attention up :P

I don't really follow how that benefits users

Right now, it's "trust us, we have analytics code but nothing happens with it"

Is that correct?

No, right now anybody can see that js code is actually not working.

anybody who inspect any page at least

Ah ok, so it's present but the user could in theory verify that no data is sent?

Yes, it's not intentional tho. Matomo is down for its own reason, but there is a content policy conflict that blocks matomo's JS

Loading failed for the <script> with source “analytics.getmonero.org/piwik.js”.

Content Security Policy: The page's settings blocked the loading of a resource at analytics.getmonero.org/piwik.js ("default-src").

I do like the idea that the project could lead by example

which leads me to support removing the code

Otherwise you're waiting for someone to enable server-side stuff

If there is the feeling that we should just remove it ASAP, i can do that. No problem. I will just ping people harder if necessary (about server logs used for analytics)

I can make a PR right now

I don't think an ASAP thing if users can verify

but I don't think waiting for server stuff is a good reason not to do it anyway

That signals a failure of process, which shouldn't block this

I would have liked to have confirmation by pigeons that server logs can be used for analytics (and they should), but since we want to remove all JS reguardless, i'm gonna do it right now. Worst case scenario we will keep working without any analytics data.

:D

could we get the analytics made public so people can see exactly that kind of data is kept?

Something like this? SarangNoether/monero-site df51990

sarang: yes, that should be it

js-begone? did you use a text editor for this or an ancient spell

Will PR after the CI build

Hehe, I figured the branch name could be whimsical :)

Unless you want me to just PR now

asymptotically: I honestly don't know, but if possible i agree we should consider it

sarang i think you can safely PR now

will do, one sec

Could you write "Closes issue" instead of "Addresses issue"? so the issue will be closed automatically once your PR is merged

sarang ^

Oh sure

done

sorry, my fault. To trigger the automatic close should be "Closes #ISSUENUMBER" without "issue" before

done

thanks

Oh don't merge yet

I forgot to remove a paragraph about Matomo

will fix now

Please check the updated privacy language

to ensure it is accurate

That preview CI is pretty slick

I could just open the link to check the pages and (lack of) scripts

OK, PR is updated

We don't really use that data to provide "statistics on the website" yet (at least AFAIK), but looks good to me. Will review it in a sec

Right, but the intent is to start doing that

Seemed prudent to leave it in

I could just open the link to check the pages and (lack of) scripts -> yeah that's what i was waiting for :D

yes sure, i didn't mean to suggest to remove it

good bot

.merge+ #1084

Added

That javascript will need to be removed from ccs.getmonero as well and maybe somewhere else

aye

in the meantime i opened an issue about using server logs for analytics, so we don't forget about it :) monero-project/monero-site #1085

Making changes for CCS now

nice one guys

& girls

also nice bot

Anywhere else it should be removed?

this takes care of getmonero.org and ccs.getmonero.org

xmr-pr best xmr employee

employee of the month