07:35:51 <fluffypony> cassact[m]1: why couldn't the subscription payment be Dollar-valued each time it's run?
07:36:16 <fluffypony> the wallet could lookup the current exchange rate on some mutually agreed sources, say CMC and CoinGecko, average the two, and off you go
17:03:37 <cassact[m]1> Yeah that’s true it could.
17:04:44 <cassact[m]1> For reasons that are opaque to me in retrospect I dismissed the idea of having that kind of integration in the wallet
17:05:05 <cassact[m]1> But yeah that would totally work
17:37:11 <midipoet> Is it just me or does the MAC CLI hash for the 16.0 download not match the website?
17:47:14 <midipoet> ignore - it's my fault. i am looking at the GUI. apologies
17:49:17 <midipoet> sorry for the false alarm - i appreciate that it was not helpful.
18:44:49 <fluffypony> midipoet: thanks for giving me a heart-attack
18:46:44 <dEBRUYNE> Not gonna lie, had an elevated heart rate for a brief amount of time :P
18:47:17 <sarang> -___-
18:47:54 <sarang> I remember some earlier suggestions to have a bot periodically download the binaries and check signatures and hashes
18:48:07 <sarang> although it was also pointed out that a super clever attacker could account for this
18:48:22 <sarang> It could at least catch errors or less-sophisticated attackers
18:48:49 <sarang> I like the idea
18:51:19 <selsta> The GUI auto updater checks hashes and if there is a mismatch if would get displayed.
18:53:13 <kinghat[m]> gui auto updater?
18:53:25 <selsta> yep, gui has an updater now
18:53:36 <kinghat[m]> v16?
18:53:37 <selsta> you still have to accept it (and manually install after it got downloaded)
18:53:41 <selsta> yes
18:53:48 <selsta> but it automatically checks hashes and signature
18:53:54 <selsta> from 2 maintainers
18:54:16 <selsta> so valid signature of 2 maintainers are required that an update gets displayed which should make it hack proof
18:54:31 <sarang> Are the verification keys hardcoded?
18:54:46 <selsta> public keys of bF, fluffy and luigi are hardcoded
18:55:16 <sarang> Where does it get the signed hashes?
18:55:27 <selsta> first one: https://web.getmonero.org/downloads/hashes.txt
18:55:32 <sarang> got it
18:55:36 <selsta> second one: https://web.getmonero.org/downloads/hashes.txt.sig (by a different maintainer)
18:55:55 <sarang> Is that the tool that mooo built, or something else?
18:56:05 <sarang> I don't have the link handy to the mooo tool
18:56:08 <selsta> not the same tool
18:57:02 <sarang> Out of curiosity, has it been tested by pointing the updater to a different binary?
18:57:11 <sarang> Even with matching (but obv. unsigned) hashes?
18:57:13 <sarang> To test it
18:58:29 <selsta> don’t understand, different binary but matching hash?
18:58:35 <selsta> just not signed?
18:58:47 <sarang> Bad wording: assuming that the adversary replaced the hash list so the hashes match the bad binary
18:59:16 <sarang> In the earlier actual attack, the hashes didn't match... but one should assume that matching hashes would be something an adversary would do
18:59:45 <sarang> The updater would need to be modified (or some local DNS hijinks played) to point to some different (but of course benign) binary
19:00:05 <sarang> My real question is: how was the tool tested?
19:01:19 <selsta> `--verify-update` flag
19:02:09 <selsta> it requires the binary, signed hashes.txt with correct hash of binary, detach signature of hashes.txt form a different maintainer
19:02:35 <sarang> Cool; do you know if these failure modes were tested?
19:02:44 <sarang> I'm not implying they weren't; simply curious to know
19:03:30 <selsta> if the hashes match the bad binary it still requires a valid signature
19:03:37 <selsta> this was tested, yes
19:03:51 <fluffypony> also step back a second
19:04:03 <fluffypony> the alert is a DNSSEC-signed DNS record
19:04:10 <fluffypony> and it checks 4 different domains
19:04:15 <fluffypony> and requires 3 of them to be valid
19:04:22 <fluffypony> so an attacked would need to compromise:
19:04:28 <fluffypony> 1. DNS records on 3 domains
19:04:40 <fluffypony> 2. the downloads on the website
19:04:48 <fluffypony> 3. the hashes file on the website
19:04:51 <fluffypony> all without anyone noticing
19:04:54 <sarang> :D
19:05:06 <sarang> and forge sigs, right?
19:05:10 <fluffypony> yes
19:05:22 <sarang> That would be... extremely impressive
19:05:24 <sarang> extremely
19:05:39 <selsta> there is obviously still the possibility of an implementation bug
19:05:47 <selsta> but we tested it quite well and mooo also reviewed it
19:05:49 <sarang> Yeah, hence my question about testing failure modes
19:05:50 <sarang> cool
19:06:33 <sarang> I also suggested (to dEBRUYNE?) to make the blog/announcement language about checking hashes _and_ signatures more direct
19:06:41 <sarang> Which was done AFAIK
19:07:02 <sarang> so first-time downloads are verified properly
19:07:12 <selsta> the ideal scenario in the future is that people download the GUI safely once and then the GUI will always automatically do the hash and sig checking
19:07:16 <selsta> but yea the first download is it
19:07:17 <sarang> yah
19:08:18 <sarang> It'd be wild to also include options to check against the repro build results
19:08:26 <sarang> Of course, there'd be a risk of sybil from that
19:08:44 <sarang> and a malicious maintainer could disable that check or something, I suppose
19:08:54 <selsta> sybil how?
19:09:07 <sarang> If repro results were checked against a source that anyone could add to
19:09:16 <selsta> we have https://github.com/monero-project/gitian.sigs/pulls
19:09:16 <sarang> Bots could post random hashes or something
19:09:29 <selsta> but obviously trusted people get merged first
19:09:31 <sarang> Right, it'd need to be from a source that's reasonably trusted
19:10:11 <sarang> Sybil's the wrong choice of term for that
19:10:53 <sarang> But anyway, given that the failure mode for that could be a malicious maintainer, it's probably a bad signal anyway
19:11:21 <sarang> The maintainer could bypass the check and just print "yep, matches!"
19:11:34 <sarang> Only way to check reliably is your own local build
19:11:58 <selsta> yep
19:12:08 <selsta> reminds me that I wanted to do a tutorial for it
19:12:33 <selsta> step by step tutorial :D
19:12:35 <sarang> Gitian?
19:12:41 <selsta> yep
19:12:44 <sarang> Nice!
19:13:05 <sarang> Along with a good explanation of why repro builds are important and useful?
19:13:47 <sarang> someday gui :)
19:13:57 <midipoet> fluffypony: yeah, sorry about that. brain freeze on my end. happens a lot.
19:14:13 <fluffypony> np
19:14:15 <midipoet> is there any solution for the GUI needing 10.12+ on MAC?
19:14:26 <midipoet> i am guessing not...
19:14:31 <fluffypony> we can spin up a MacStadium box again and use it for builds?
19:14:51 <selsta> Apple dropped support for it 3 years ago, now also Qt dropped support for it
19:14:57 <selsta> so it becomes difficult to support at this point
19:18:06 <fluffypony> https://support.apple.com/en-us/HT201222
19:18:16 <fluffypony> yeah looks like 10.13 is still getting updates, but not 10.12
19:18:27 <selsta> midipoet is asking about 10.11
19:18:29 <fluffypony> last security update to 10.12 was Sep 2019
19:18:37 <selsta> it supports 10.12
19:18:43 <fluffypony> last security update for 10.11 was July 2018
19:18:56 <selsta> hmm 2 years ok
19:19:00 <midipoet> wow. i didn't realise i was sooo far behind.
19:19:02 <midipoet> hmm
19:19:07 <fluffypony> so we already support a version of macOS that no longer gets security updates
19:19:36 <selsta> Qt 5.9 was the last LTS version that supported 10.11
19:19:38 <selsta> but it is EOL now
19:19:44 <fluffypony> and I don't think encouraging people to run a Monero wallet on that is a good idea
19:19:57 <selsta> We should not use a framework without security updates
19:20:20 <dEBRUYNE> +1
19:20:22 <selsta> CLI still supports 10.11
19:20:26 <fluffypony> plus 10.13 runs on old Macs -
19:20:27 <fluffypony> iMac: Late 2009 or later
19:20:28 <fluffypony> MacBook: Late 2009 or later
19:20:28 <fluffypony> MacBook Pro: Mid 2010 or later
19:20:28 <fluffypony> MacBook Air: Late 2010 or later
19:20:28 <fluffypony> Mac Mini: Mid 2010 or later
19:20:29 <fluffypony> Mac Pro: Mid 2010 or later
19:20:35 <fluffypony> so no reason not to update to 10.13
19:22:00 <fluffypony> allegedly extended support for 10.13 will end in Sept 2020, and then everyone will need to be on 10.14, which changes the supported devices somewhat
19:22:23 <fluffypony> you mostly need a 2012 or newer device to do that
19:22:47 <midipoet> i understand the issue. just trying to figure the best way to deal with the situation on my side...
19:22:55 <fluffypony> midipoet: what prevents you from updating?
19:23:17 <midipoet> 32 bit audio software
19:23:37 <fluffypony> hmmmm - can't you run it in a macOS VM in Parallels?
19:23:48 <sarang> Oh yeah, they dropped 32-bit support entirely, right?
19:23:50 <selsta> didn’t only 10.15 killed 32bit?
19:24:02 <selsta> so you can upgrade to 10.12-10.14
19:24:42 <fluffypony> oh yeah - they come with warnings in everything but then don't work at all in 10.15
19:24:43 <midipoet> you may be right. i have to look into it properly. or move my monero wallet off this mac - which seems far easier.
19:25:22 <midipoet> either way, thanks for the security check up peeps ;-)
19:25:25 <selsta> can’t wait to run GUI on ARM mac :D
19:25:44 <selsta> soon^tm
19:25:56 <sarang> Oh yeah, is that actually happening?
19:26:05 <sarang> Heard rumblings on it for a while
19:26:13 <selsta> apparently, will be announced this month
19:26:19 <fluffypony> heard the same
19:26:22 <sarang> I wonder how far into the line it'll extend
19:26:25 <fluffypony> but first hardware will only come out next year
19:26:32 <sarang> ARM on the pro line seems like a risky move
19:26:42 <sarang> but maybe for the consumer line?
19:26:46 <sarang> e.g. the airs
19:26:53 <fluffypony> sarang: they'll do the Air and maybe bring back the 12" Macbook next year
19:26:55 <fluffypony> and then Pro the year after
19:27:13 <fluffypony> (I'm guessing)
19:27:41 <fluffypony> there's already a large body of libraries and stuff with ARM support because of iPadOS and iOS
19:28:03 <sarang> But so many major players will need to overhaul, no?
19:28:44 <sarang> But I suppose "everyone needs to overhaul everything" is not unheard of for Apple =p
19:28:58 <selsta> A lot of open source programs already support ARM
19:29:12 <selsta> I guess some less supported niche apps will be more difficult
19:29:24 <sarang> Sure, but I'm wondering about the stuff that Mac Pro folks might need that don't already
19:29:24 <fluffypony> they'll probably also have an emulator for a few years
19:29:28 <sarang> (I don't know much about that)
19:29:40 <fluffypony> and they'll get Adobe, Microsoft, etc. to buy into it
19:29:48 <sarang> Apple spent years not caring about the Pro untli the recent overhaul
19:29:56 <sarang> Best not to upset those users once again
19:30:14 <fluffypony> sarang: Mac Pro I agree, but MacBook Pro they can probably take the risk in 2 years
19:30:19 <selsta> I still have a 2014 Pro one, these were the best IMO
19:30:21 <sarang> That makes more sense
19:30:25 <selsta> until 2015
19:30:26 <sarang> I wonder what it'll do for battery life
19:34:08 <selsta> good things hopefully :P
19:34:17 <selsta> can’t get worse I guess
20:20:34 <midipoet> selsta: lol. i recently bought a 2012 Pro for someone. rock of a machine.
20:24:36 <dsc_> +1 older macbooks
20:24:50 <dsc_> +1 older thinkpads
21:15:27 <UkoeHB_> 12 Pro works fine if you get SSD, upgrade RAM, and avoid the newer OS
22:51:18 <sgp_> An update/overview of the website's security features could be a cool read