14:34:21 <ErCiccione[m]> https://github.com/monero-project/monero-site/issues/1081
14:35:00 <ErCiccione[m]> Is there a solution for this? I cannot test myself what are the hops the requests goes through
14:35:38 <ErCiccione[m]> damn temporary win8 brick
14:37:29 <sarang> the linux64 URL 302s to this: http://dlsrc.getmonero.org/gui/monero-gui-linux-x64-v0.16.0.2.tar.bz2
14:37:40 <sarang> ^ fluffypony etc.
14:38:16 <sarang> which in turn 301s to this: https://dlsrc.getmonero.org/gui/monero-gui-linux-x64-v0.16.0.2.tar.bz2
14:38:40 <sarang> which then 200s
14:38:51 <sarang> So it looks like the first redirect is HTTP for some reason, which is not good
14:46:47 <ErCiccione[m]> thanks sarang :)
14:47:09 <ErCiccione[m]> ping pigeons too
14:50:03 <sarang> np
15:05:28 <fluffypony> tks sarang
15:05:41 <fluffypony> we'll have to check the nginx file to see how it redirects
15:06:29 <sarang> Would there be any legitimate reason for this setup?
15:32:06 <fluffypony> yes
15:32:17 <fluffypony> it's wrong, but it's because updates.getmonero.org didn't support TLS
15:32:28 <fluffypony> moneromooo: am I correct in saying that the auto-updater can now handle HTTPS?
15:32:36 <sarang> ah
15:32:52 <fluffypony> because then we can just force TLS
15:32:57 <sarang> Yeah
15:33:07 <sarang> Wouldn't be dangerous if everyone checks hashes and signatures
15:33:14 <sarang> but MITM is no good
15:33:43 <sarang> Could you at least force HTTPS for those links, and if needed use HTTP for the updater since it always checks signatures?
15:34:34 <sarang> So at least an HTTP-routed updater would fail secure
15:34:40 <ErCiccione[m]> Yeah but that's a big "if" :)
15:34:50 <ErCiccione[m]>  * That's a big "if" :)
15:35:28 <sarang> HTTPS for links and _maybe_ HTTP for updater (but ideally not) would result in everyone failing secure (unless they manually do the HTTP link)
15:35:29 <fluffypony> sarang: yes - that's a workaround if we still need to support HTTP
15:35:46 <ErCiccione[m]> (I was just joking about "if everyone checks hashes", my message could have been relayed with a delay)
15:36:05 <sarang> ErCiccione[m]: yeah, relying on hash and signature checks to avoid MITM seems like a bad idea
15:36:21 <moneromooo> It does.
15:36:36 <sarang> :D
15:36:53 <ErCiccione[m]> Yep 🙂 Trusting people to do what's best for them? what could go wrong?
15:36:54 <fluffypony> moneromooo: it does as in we can dump HTTP?
15:37:00 <moneromooo> Yes.
15:37:15 <fluffypony> ok cool
15:37:25 <ErCiccione[m]> Cool
15:37:30 <sarang> ErCiccione[m]: checking hashes and signatures is a bit of a PITA, though important
15:37:41 <sarang> Best to provide some layers of protection for people who don't
15:37:48 <sarang> Even though it's not possible to remove all risk
15:37:49 <moneromooo> Just make sure you inlcude a cipher suite epee+openssl can use.
15:38:02 <sarang> MD5+DES, got it
15:38:18 <moneromooo> Who are you and what have you done with sarang ?
15:38:26 <ErCiccione[m]> 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
15:38:43 <sarang> Check hashes, or hashes+signatures?
15:39:23 <fluffypony> ok I've flipped on HTTPS everywhere for the whole of getmonero.org
15:39:26 <fluffypony> and enabled HSTS
15:39:31 <ErCiccione[m]> Many seem to at least check hashes, for what i noticed at least
15:39:34 <fluffypony> and requested we go into the HSTS preload list
15:39:45 <sarang> fluffypony: so the redirect should be gone? (will test)
15:39:45 <fluffypony> so if anything breaks we'll know in the coming weeks that we're relying on HTTP for something
15:39:49 <fluffypony> sarang: no not yet
15:39:52 <fluffypony> we're fixing that too
15:39:58 <ErCiccione[m]> That's a relative "many" tho
15:39:58 <sarang> ah ok
15:40:09 <sarang> Please let us know when that can be tested
15:40:29 <sarang> ErCiccione[m]: checking only hashes doesn't do much of anything
15:41:22 <sarang> And I don't want people to think it does more than it actually does
15:41:41 <ErCiccione[m]> It's still something tho. It allowed us to notice we were showing wrong hashes in the downloads page recently
15:41:44 <ErCiccione[m]> fair enough
15:41:49 <sarang> Sure, but that was lucky
15:42:11 <sarang> A more clever/capable attacker would have changed those too
15:42:22 <sarang> Oh, you mean the switched hashes
15:42:23 <sarang> yes
15:43:21 <sarang> I think the download page language on signature verification should be much stronger, FWIW
15:43:42 <sarang> To say that the only way to guarantee the binaries you have are those intended by the maintainers, you need to do both steps
15:43:53 <moneromooo> "Your hardware might be pwned anyway, don't bother"
15:44:03 <sarang> and that if you also wish to check that the maintainers honestly compiled the right code, you should do repro builds
15:44:09 <sarang> moneromooo:  :(
15:44:27 <moneromooo> OK. Paranoid enough, but not too much.
15:44:44 <sarang> Well, I think it should be more clear about what steps mitigate what risks
15:45:18 <sarang> Checking hashes could be just asking the attacker "hey attacker, are you an attacker?" "um, no..."
15:46:24 <moneromooo> 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...
15:46:43 <moneromooo> But sure, explaining what is what is good.
15:47:06 <sarang> Yeah, and the real risk is a malicious binary, which has happened
15:47:12 <sarang> Those two steps eliminate that risk
15:47:15 <sarang> Problem solved
15:47:24 <sarang> People worried about other risks can/should take extra steps
15:47:56 <sarang> Not everyone cares about the repro build, and that's fine
15:48:12 <sarang> But people who do care can (and do) run it
15:48:46 <fluffypony> ok we've solved it, we're rolling it out for all the URLs, should be done in a few mins
15:48:53 <sarang> Nice, that was fast
15:49:45 <sarang> Probably worth noting in that issue why it was set up the way it was
15:49:51 <sarang> (once it's fixed, that is)
15:50:49 <fluffypony> ok all fixed
15:50:53 <sarang> testing
15:50:56 <fluffypony> pigeons did all the effort
15:51:02 <fluffypony> all I did was clear the cache a bunch
15:51:10 <sarang> no change yet
15:53:38 <sarang> probably still a caching issue?
15:53:48 <sarang> I'm getting a 302 to the http loation
15:54:30 <fluffypony> oh hmmm
15:54:35 <fluffypony> something still cached
15:54:36 <fluffypony> lemme fix
15:54:54 <sarang> unless `curl` is caching locally
15:55:03 <sarang> nope, tried on a different machine
15:55:14 <fluffypony> oh I rushed it sorry
15:55:17 <fluffypony> pigeons is still busy
15:55:18 <fluffypony> my bad
15:55:25 <sarang> got it
16:00:26 <fluffypony> yay all works
16:00:49 <sarang> Confirmed!
16:00:59 <fluffypony> party emoji!
16:01:06 <sarang> Someone want to note this on the issue?
16:01:08 <sarang> https://github.com/monero-project/monero-site/issues/1081
16:01:16 <sarang> The original reasoning would be good too
16:01:17 <fluffypony> I'm doing it now
16:01:28 <sarang> cool
16:01:35 <sarang> I'll confirm the test after you comment
16:01:39 <sarang> in case that's helpful
16:02:47 <ErCiccione[m]> Thanks pony and pigeons. I have a comment ready, but go for it :)
16:08:52 <sarang> :D
16:17:09 <sarang> Has there been any movement on removing analytics?
16:17:14 <sarang> It was brought up a while ago
16:17:39 <asymptotically> aren't they already gone?
16:18:14 <sarang> Issue: https://github.com/monero-project/monero-site/issues/978
16:23:04 <ErCiccione[m]> asymptotically: analytics are not working but the JS code is still on the website
16:23:34 <ErCiccione[m]> Personally, i'm fine with remove all JS and use only server logs for anamlytics
16:23:42 <ErCiccione[m]> *removing
16:24:23 <dsc_> access_logs /dev/null; @ nginx ? :P
16:26:29 <sarang> OK, anything that would need to be done before just making a PR that nukes the JS code?
16:27:30 <ErCiccione[m]> 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
16:28:07 <sarang> I don't really follow how that benefits users
16:28:22 <sarang> Right now, it's "trust us, we have analytics code but nothing happens with it"
16:28:43 <sarang> Is that correct?
16:28:53 <ErCiccione[m]> No, right now anybody can see that js code is actually not working.
16:29:03 <ErCiccione[m]> anybody who inspect any page at least
16:29:34 <sarang> Ah ok, so it's present but the user could in theory verify that no data is sent?
16:30:49 <ErCiccione[m]> 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
16:31:13 <ErCiccione[m]> Loading failed for the <script> with source “https://analytics.getmonero.org/piwik.js”.
16:31:16 <ErCiccione[m]> Content Security Policy: The page's settings blocked the loading of a resource at https://analytics.getmonero.org/piwik.js ("default-src").
16:31:33 <sarang> I do like the idea that the project could lead by example
16:31:38 <sarang> which leads me to support removing the code
16:31:50 <sarang> Otherwise you're waiting for someone to enable server-side stuff
16:32:43 <ErCiccione[m]> 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)
16:33:27 <ErCiccione[m]> I can make a PR right now
16:33:30 <sarang> I don't think an ASAP thing if users can verify
16:33:43 <sarang> but I don't think waiting for server stuff is a good reason not to do it anyway
16:34:05 <sarang> That signals a failure of process, which shouldn't block this
16:39:46 <ErCiccione[m]> 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.
16:40:28 <sarang> :D
16:40:45 <asymptotically> could we get the analytics made public so people can see exactly that kind of data is kept?
16:42:22 <sarang> Something like this? https://github.com/SarangNoether/monero-site/commit/df5199067a36a60273c4169f889ca4485a6a5412
16:43:25 <ErCiccione[m]> sarang: yes, that should be it
16:43:32 <asymptotically> js-begone? did you use a text editor for this or an ancient spell
16:43:38 <sarang> Will PR after the CI build
16:43:47 <sarang> Hehe, I figured the branch name could be whimsical :)
16:44:10 <sarang> Unless you want me to just PR now
16:44:30 <ErCiccione[m]> asymptotically: I honestly don't know, but if possible i agree we should consider it
16:44:42 <ErCiccione[m]> sarang i think you can safely PR now
16:45:01 <sarang> will do, one sec
16:45:50 <sarang> https://github.com/monero-project/monero-site/pull/1084
16:47:30 <ErCiccione[m]> Could you write "Closes issue" instead of "Addresses issue"? so the issue will be closed automatically once your PR is merged
16:47:32 <ErCiccione[m]> sarang ^
16:47:38 <sarang> Oh sure
16:47:54 <sarang> done
16:48:50 <ErCiccione[m]> sorry, my fault. To trigger the automatic close should be "Closes #ISSUENUMBER" without "issue" before
16:49:27 <sarang> done
16:50:00 <ErCiccione[m]> thanks
16:53:58 <sarang> Oh don't merge yet
16:54:05 <sarang> I forgot to remove a paragraph about Matomo
16:54:08 <sarang> will fix now
16:56:04 <sarang> Please check the updated privacy language
16:56:12 <sarang> to ensure it is accurate
16:56:45 <sarang> https://github.com/monero-project/monero-site/pull/1084/files#diff-0f2867d7019ab25f2097792dc222c701
16:57:38 <sarang> That preview CI is pretty slick
16:57:59 <sarang> I could just open the link to check the pages and (lack of) scripts
16:58:09 <sarang> OK, PR is updated
16:58:36 <ErCiccione[m]> 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
16:58:59 <sarang> Right, but the intent is to start doing that
16:59:05 <sarang> Seemed prudent to leave it in
16:59:11 <ErCiccione[m]> I could just open the link to check the pages and (lack of) scripts -> yeah that's what i was waiting for :D
16:59:25 <ErCiccione[m]> yes sure, i didn't mean to suggest to remove it
17:00:38 -xmr-pr- erciccione opened issue #1085: Set up Matomo to parse server logs for analytics
17:00:38 -xmr-pr- > https://github.com/monero-project/monero-site/issues/1085
17:00:38 -xmr-pr- SarangNoether opened pull request #1084: Remove analytics
17:00:38 -xmr-pr- > https://github.com/monero-project/monero-site/pull/1084
17:01:24 <sarang> good bot
17:07:04 <ErCiccione[m]> .merge+ #1084
17:07:05 <xmr-pr> Added
17:07:35 <ErCiccione[m]> That javascript will need to be removed from ccs.getmonero as well and maybe somewhere else
17:08:02 <sarang> aye
17:09:01 <ErCiccione[m]> in the meantime i opened an issue about using server logs for analytics, so we don't forget about it :) https://github.com/monero-project/monero-site/issues/1085
17:09:42 * ErCiccione[m] going afk for at least one hour
17:10:37 <sarang> Making changes for CCS now
17:14:02 <sarang> https://repo.getmonero.org/monero-project/ccs-front/-/merge_requests/31
17:17:29 <dsc_> nice one guys
17:17:32 <dsc_> & girls
17:18:37 <dsc_> also nice bot
17:18:49 <sarang> Anywhere else it should be removed?
17:19:09 <sarang> this takes care of getmonero.org and ccs.getmonero.org
17:36:30 <selsta> xmr-pr best xmr employee
17:41:16 <dsc_> employee of the month