repro builds wouldn't prevent any of that

people downloading don't check hashes, and that's not going to change

the auto-updater is the closest thing we can do to checking it for them

^ also true

all that repro builds do is prevent the person finalising the build from compromising it

it's not like when binaryFate uploads a binary any of us go and disassemble it

ain't nobody got time fo date

*dat

fluffypony: btw do you have any idea how we could move the mac archive from tar.bz2 to .dmg while not breaking updater?

a redirect maybe? not sure if the software would follow it

hmmmm

we could test a redirect

the problem is that you can automatically unpack a tar.bz2 and overwrite the existing one

I don't know if there are automation tools for handling a DMG

I mean, there must be

but the existing code won't know what to do with it

don’t think we have this code

or not aware of it

the updater only downloads the new file

do the notary tools insist on producing a .dmg?

yes

I thought they produce .apps

and the .app is signe

*signed

.dmg or .zip

we can unpack the .zip and repack it as .tar.bz2 without losing the sig

I'm 25% certain

lol

yea does not work lol

blah

the .dmg gets signed and the .app

apparently

but the .zip doesn't get signed

or is it a zip of a dmg

no, but there were issues with the .zip

that I don’t remember currently

.dmg was better

are these signed per-machine or a single universal sig?

(app store app installs are signed for that machine only, afaik)

I think universal

I remember the issue with .zip now, you can’t staple the result

meaning that apple’s server get pinged

with dmg you can staple the "signature" and it also works offline without pinging apple

we had the idea of doing it in two steps

add the code to download .dmg instead of .tar.bz2 in the next release

and then the release afterwards we bundle it as dmg

but this will only work for those who updated to the latest version

I think we can expect teething issues for now

so don't expect perfect forward compatibility

we can add the code in, and do the next one as a .tar.bz2

and then .dmg thereafter

we just need to automatically mount the dmg -> copy the .app to where the current one is

(which may not be /Applications)

fluffypony: the auto updater only verifies the file and opens the file explorer, no auto extracting currently

so should be ok with .dmg

ah ok

is the plan to go full auto-update eventually?

maybe, probably not trivial to do cross platform

would require a second binary that spins up -> deletes existing app -> replaces it with the new one -> restarts app

would be a nice to have in the future

possibly make this a seperate project that is able to manage both monero-gui and monero binaries (starting, stopping, updating)

we need to create Steam/Battle.net, for crypto

half joking, half not

dsc_: github.com/moneromooo-monero/monero-update

needs to be picked up, but moneromooo already started it

if someone wants to run with it I'm happy to re-home it to the main GitHub

I have a patch for it to work with the GUI. I'm just waiting for repro builds to push it.

i was thinking of only checking the binary hashes from two or more locations and thats it. with immutable git repo to prevent what pony was talking about backdating commits and repo builds when that happens. ill stop bringing it up as the updater is already overkill.a

* i was thinking of only checking the binary hashes from two or more locations and thats it. with immutable git repo to prevent what pony was talking about backdating commits and repo builds when that happens. ill stop bringing it up as the updater is already overkill.

.merges

2933 conflicts

xiphon: ^

2963 also

we might have to revert 2947, it seemed like a simple patch and I also tested it a bit but it doesn’t fully work as expected.

luigi1111w: resolved merge conflicts