07:43:41 <ErCiccione> Once again somebody suggested to give the possibility to download the wallets as torrents. That's something i would like to have to decentralize a bit the downloads and not rely uniquely on core's server. I offered two possible solutions: https://github.com/monero-project/monero-site/issues/1629#issuecomment-842091854
07:44:09 <ErCiccione> binaryfate i pinged you there ^
07:54:43 <binaryFate> thanks will check
10:56:32 <ErCiccione> opinions about this? https://github.com/monero-project/monero-site/issues/811. Old releases are not downloadable on getmonero, but we link to these releases from github. So, the binaries are downloadable, but people have no way to verify hashes. I think we have two solutions here:
10:57:06 <ErCiccione> actually three:
10:58:13 <ErCiccione> 1. we ship the hashes with the release archive, so people will always have the hashes to compare, doesn't matter when they download the binaries
10:58:25 <ErCiccione> 2. We remove old releases from download.getmonero
10:59:33 <ErCiccione> 3. we don't use direct links to the releases on github. But instead the relative address (e.g https://$server_name/linux64)
11:00:24 <ErCiccione> in any case we shouldn't make binaries publicly available if we cannot give the possibility to verify them
11:02:10 <ErCiccione> see for example https://github.com/monero-project/monero/releases/tag/v0.12.2.0
12:39:18 <binaryFate> While not super convenient, they can check the hashes with the git history of hashes.txt
13:17:55 <ErCiccione> yeah, but nobody is going to do that.
13:43:59 <binaryFate> well nobody is going to download old releases either :)
13:44:55 <binaryFate> I mean how much of an edge case are we talking about? Granted checking the file history is not convenient but how many people are going to need this and why?
13:45:06 <binaryFate> It's reasonably easy here https://github.com/monero-project/monero-site/commits/master/downloads/hashes.txt
14:01:17 <ErCiccione> I don't know if it's so much and edge case. I mean, for old releases sure, but this happens also for the release before the last one and people might have reasons to use a slightly older release
14:02:34 <ErCiccione> pointing people to the file and ask them to roll back history until they find the right commit it's more a hack, but if we want to keep things as they are i guess it's fine, i can add instructions to the readme so we don't have to think about the issue anymore.
14:24:32 <binaryFate> Unless I misunderstand 1. it's a chicken and egg, we can't include hashes of an archive in the archive
14:31:23 <selsta> binaryFate: I think hashes can be updated now
14:58:41 <binaryFate> selsta dns?
14:58:53 <selsta> yes
14:59:11 <binaryFate> oki
15:09:35 <ErCiccione> 1. it's a chicken and egg <-Yes. That's true. Disregard 1
15:14:27 <selsta> 12:58 <ErCiccione> 2. We remove old releases from download.getmonero <-- why?
15:14:42 <selsta> they are useful in some cases
15:15:35 <ErCiccione> yeah i know, but people cannot verify they are legit unless they go through the git history of the hash file
15:16:12 <ErCiccione> if we don't care we can just leave everything as it is, but imo if we give the binaries we also have to give the hashes
15:16:24 <selsta> we do give hashes?
15:16:30 <selsta> just not signed
15:19:03 <binaryFate> dns updated
15:20:09 <ErCiccione> yeah in the blog posts, i hadn't considered that. Then it's ok
15:21:25 <ErCiccione> well, somebody want them signed: https://github.com/monero-project/monero-site/issues/811#issuecomment-842337979
15:22:48 <ErCiccione> we can just give people that script :P
15:24:06 <binaryFate> maybe we could have a historical-hashes.txt that is just an ever expanding list of all hashes for each release. And hashes.txt remains just the last version.
15:24:27 <binaryFate> Would be an easy workflow as far as I'm concerned
15:24:51 <ErCiccione> sounds good to me
15:34:34 <selsta> ErCiccione: the hashes are also in the github release notes
15:35:31 <ErCiccione> yeah but not signed
15:37:12 <selsta> we can save each file as e.g. hashes-v0.17.1.0.txt while keeping hashes.txt up to date
15:37:26 <selsta> but I doubt luigi wants to go through all previous release notes and update them
15:38:03 <ErCiccione> i think latest idea is to have one file with all previous hashes and one with the last ones
15:39:04 <selsta> yes but that still will require someone to update all the previous release notes
15:40:16 <binaryFate> I don't think we need to update any old release notes, regardless of what we put in place going forward
15:40:59 <selsta> in that case I would just do it with hashes-v0.17.2.0.txt way were we link to this file from release notes
15:41:06 <selsta> for future releases
15:42:57 <selsta> where*
15:48:20 <binaryFate> As I said here https://github.com/monero-project/monero-site/issues/811#issuecomment-842419160 I don't like having one hash file per version. I think it will be confusing to a lot of people, in particular with caching issues and potential versions mismatch
15:49:25 <selsta> I don't understand your point.
15:49:43 <selsta> The hash file per version would be linked from release notes and otherwise isn't visible.
15:49:45 <binaryFate> If we don't use a redirect hashes.txt -> hashes-<last_version>.txt it's probably fine though
15:50:02 <selsta> Caching issues how?
15:50:09 <selsta> Yea, no redirect.
15:50:31 <binaryFate> Yeah I jumped on assuming instead of hashes.txt we would simply redirect to last version which would bring a nightmare of caching
15:50:42 <binaryFate> That could work then