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: monero-project/monero-site #1629#issuecomment-842091854

binaryfate i pinged you there ^

thanks will check

opinions about this? monero-project/monero-site #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:

actually three:

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

2. We remove old releases from download.getmonero

3. we don't use direct links to the releases on github. But instead the relative address (e.g $server_name/linux64)

in any case we shouldn't make binaries publicly available if we cannot give the possibility to verify them

see for example github.com/monero-project/monero/releases/tag/v0.12.2.0

While not super convenient, they can check the hashes with the git history of hashes.txt

yeah, but nobody is going to do that.

well nobody is going to download old releases either :)

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?

It's reasonably easy here github.com/monero-project/monero-si…commits/master/downloads/hashes.txt

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

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.

Unless I misunderstand 1. it's a chicken and egg, we can't include hashes of an archive in the archive

binaryFate: I think hashes can be updated now

selsta dns?

yes

oki

1. it's a chicken and egg <-Yes. That's true. Disregard 1

12:58 <ErCiccione> 2. We remove old releases from download.getmonero <-- why?

they are useful in some cases

yeah i know, but people cannot verify they are legit unless they go through the git history of the hash file

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

we do give hashes?

just not signed

dns updated

yeah in the blog posts, i hadn't considered that. Then it's ok

well, somebody want them signed: monero-project/monero-site #811#issuecomment-842337979

we can just give people that script :P

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.

Would be an easy workflow as far as I'm concerned

sounds good to me

ErCiccione: the hashes are also in the github release notes

yeah but not signed

we can save each file as e.g. hashes-v0.17.1.0.txt while keeping hashes.txt up to date

but I doubt luigi wants to go through all previous release notes and update them

i think latest idea is to have one file with all previous hashes and one with the last ones

yes but that still will require someone to update all the previous release notes

I don't think we need to update any old release notes, regardless of what we put in place going forward

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

for future releases

where*

As I said here monero-project/monero-site #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

I don't understand your point.

The hash file per version would be linked from release notes and otherwise isn't visible.

If we don't use a redirect hashes.txt -> hashes-<last_version>.txt it's probably fine though

Caching issues how?

Yea, no redirect.

Yeah I jumped on assuming instead of hashes.txt we would simply redirect to last version which would bring a nightmare of caching

That could work then