hey devs, any plans to digital sign the packages?

PGP sign?

how is that more effective than signing the hashes?

does rpc_access_tracking only track rpc access through the new payment system? called it, and got 404/empty as response

hyc: not PGP, but with a code signing certificate

it's like 60 bucks a year, dead cheap

and it will provide security, because 70% don't verify hashes when downloading and running stuff

maxwilliamson: what OS?

Is this code signing certificate for Windows? Because there is a separate one for macOS and probably no such thing for Linux.

maxwilliamson: Where did you see a proper code-signing certificate for USD 60? I just randomly looked them up at digicert and saw a price of around USD 500

Anyway, how many people will know that the code *must* be signed and really do not install if it's missing?

And what stops attackers to buy a code signing certificate themselves, or use a leaked one, and then count on people to not notice the different owner?

And yes, as selsta said, probably Windows-only solution anyway, so less than ideal

Yeah, and people use windows *a lot*

pretty cheap for security it will offer

A lot of people actually check for code signatures because windows warns when the program is not signed.

Right, people use Windows a lot, and maybe indeed it's the Windows people most in need of some sort of safety net, being not fluent with CLI tools, hashes etc.

The warnings of Windows about binaries that are not signed are a double-edged sword: So many programs are *not* signed that people may simply click the warning away, as they usually do

By the way, I also see the non-trivial question of who would be the owner of the certificate

Also how does a certificate work together with reproducible builds?

Well, I think the thing most in need of a certificate is the GUI wallet Windows installer, which indeed would become un-reproducible with a signing certificate, that's true

But I can't deny that quite in general a valid signature there would at least *look* good, make a good impression

"Signed by MEA"

For people who remember that :)

It has to be a real organisation/person to get code signing certificate.

Yes, I think so, and that would probably be "non-trivial" to agree on somebody / something

And to found something just for that is probably overkill

rbrunner: many programs are indeed signed and people notice that.

selsta: just code sign the installer. don't sign things that needs to be reproduced.

Agreed. But we are talking about the opposite: What do they do if it's not signed? Do they do the right thing and say "Ok, no Monero for me then with this thing here, have to investigate", or do they say, what the heck, I install

Why do you see no need to reproduce the installer? I am lazy, but I really should check the current installer, Fluffypony could have put anything in there :(

Installer builds are reproducible

rbrunner: GUI is not reproducible

Right, the GUI itself not, but the installer. And maybe the GUI itself will get reproducible in the future ... or is that a completely lost case?

at least tor code signs and still has reproducible builds

nvm, doesn't affect me. don't want to waste energy on this

rbrunner: No, first we migrate to cmake and then we try to make it reproducible :P

Ok. At least there is hope

I’ve been looking into notarizing the macOS builds, which is a step before signing I think.

maxwilliamson: Do you know of a good explanation how Tor does that, sign code *and* having reproducible builds?

As certainly only the key owner can sign, how other people can reproduce? Maybe I overlook something.

It depends on how hash of the binary is calculated. They probably have a hash _before_ signing and compare it and check that signed part of the binary is the same.

Yeah, that crossed my mind. But does not erase the fact that here you execute untrustworthy code before you get at the thing you can check the hash of, right?

Untrustworthy in principle only of course, because non-reproducible

It's signed after all

In bitcoin, you'll see separate sigs for signed / unsigned builds:

> Ok. At least there is hope

Yes, TheCharlatan has already made some progress on reproducible builds for the GUI. Still *very* far from done though. Maybe by the end of 2020 :-)

make release-static just barfed all over me

What do people think about the following idea of mine: While syncing make the daemon periodically display time estimates until fully synced

Estimated in a sane way, with suitably sliding averages, also taking into account verification speed differences pre/post RingCT, pre/post Bulletproofs, block size averages etc.

Thus (hopefully) also being able to give useful total estimates for syncing from scratch

Maybe make the estimates also available through daemon RPC so wallets could display them to users if they so wish

I could see me implementing that over the next few weeks

yeah, sounds nice. would be great for gui

That was a pretty low priority thing I wanted to do. I'd totally ACK it if decent.

Puh. Lucky me that you didn't do that already then :)

Yeah, it has to be decent to be useful. I don't want to produce another "Now it's 1 hour, now it's 10 years" estimator like Windows still has

What might also be nice, and possibly a byproduct of this, would be to determine what is the bottleneck.

"You know, it'd go faster if you had a faster $THINGIE"

Noting that currently, sync is often still waiting for blocks to arrive.

Maybe less so now that you can set the span download cache size though.

I see.

Might be fun to try it on Testnet and Stagenet also, if it still gives good estimates in those "edge cases" maybe a good test

Testnet will likely give you PoW performance.

Hmm. Actually, I take that back. I'm not sure it will...

would be nice to be able to bundle 'set' commands in one line, or in a copy/paste friendly manner.

I'm creating a bunch of wallets, would like to get them to behave as I like easily. I think it would involve pasting a single line and then it would ask for password only once to set up everything.

What would be the intuitive syntax for this? Semi-colon? "set <command_1>; <command_2>; ..."

"monero-wallet-cli --wallet-file foo set foo bar ?

Oh, you want a single line, rather than two set commands ?

You can paste stuff with a newline in it, right ?

Or does that not work ?

Can paste stuff with newline but it asks for password for each of them

does the config file support set?

"monero-wallet-cli --wallet-file foo set foo bar" is nice, but I can't put two different set commands in there I think?

like "monero-wallet-cli --wallet-file foo set foo bar set foo2 bar2" does not seem to do anything about the second set command

missed the conversation this morning: Code signing plays well with reproducibility. This is the usual workflow: have someone sign the code with a key corresponding to the code signing cert. Have that somebody detach his signature from the binary with ossl signcode or a similar tool. Add the detached signature to the source tree. Run a normal reproducible build. Let builders attach the signature again when

the build is done, thus preserving reproducibility.

is there something going on with rpc-payments? I had a node running fine then tried to add the rpc payment stuff and got this: paste.fedoraproject.org/paste/lAxqeiFavDlHWnHpnsL2sQ

hrm, found it

so im running with --rpc-restricted-bind-port 18089, but the payment flags are causing a warning that I don't have a restricted rpc

so it seems to want the --restricted-rpc flag, not the one that specifies the port

hrmmm.. we lost the whole up arrow to repeat command thing?

Is that with your static build ?

Btw, did you solve the libusb-1.0.a thing ?

no, i just compiled regular.

instead of static

Command history works here.

dpkg -S libusb-1.0.a | sed s/\:.*// | xargs dpkg --get-selections

Sent a tx from wallet A to wallet B, wallet B said upong getting tranfser "NOTE: this transaction uses an encrypted payment ID: consider using subaddresses instead"

did it have an encrypted payment id?

I am 100% sure there was no encrypted payment ID. Is the detection of encrypted payment ID or not based on a heuristic or?...

huh, static just built fine iDunk . mystery

It did here as well.

rpc payment is working fine for me, at least on cli

welp, no rpc payment functionality in the GUI

binaryFate: Each transaction now has an encrypted payment ID attached

Regardless of whether you specified it

maybe consider removing that warning? seems meh

Each transaction now has an encrypted payment ID attached <- Also the ones to subaddresses, which then would also trigger the warning?

Really seems like some false alarm to me

That I am not sure of

Well, without that txs to subaddresses would stand out, which would surprise me immensely

Oh ok, I hadn't noticed before. This does not make sense to warn user about doing X if he did not do X.

Let's continue to speculate until moneromooo spoils all the fun with facts :)

And maybe recommending Y which then would result in the very same warning ...

<rbrunner> Well, without that txs to subaddresses would stand out, which would surprise me immensely <-- they did stand out in the past, or do you mean it going forward?

From the point when the feature with random payment IDs started. I assume every tx gets one, whether to address or subaddress

Think this was implemented last HF

I think I saw that warning about 2 weeks ago for the first time.

Not reporting it, assuming it will get corrected quickly

Maybe that non-reporting was not so clever ...

it was reported, even on reddit

there was nothing new, just a misunderstanding of many people who did not follow previous discussions about subaddresses closely enough (including me)

You mean the preference? To nudge people now towards subaddresses?

rbrunner: As far as I can see, the warning is new, an encrypted pID being added for each transaction is not

Sounds right

I mean that you can distinguish transfers to subaddresses or non-subaddresses

Speculate about... ?

Payments to a standard address that don't have payment id get a dummy short one.

Sending to subaddresses don't.

About the warning, maybe I did not PR something, IIRC it's supposed to warn for a non zero one only.

Well, it... compares without decrypting. That's why it triggers when it should not. Easy to fix.

Pardon my ignorance - why not just slap a dummy short one on transfers to subaddresses also, so they blend in as well?

Or are subaddress transfers already recognizable for other reasons, so that would be pointless?

There are no integrated subaddresses.

Right. I was thinking on a more technical, data-structure level. Do I remember correctly - encrypted payment ids go into txextra?

Or were the unencrypted ones?

Both.

So you could put one into txextra also for a transfer to a subaddress?

Just to make it not stand out - on that low level.

But I am sure the problem is my lack of detail knowledge, that must not be possible somehow, otherwise we would do it already

Eve can tell which outputs are to a subaddress. Currently anyway. So since there are no integrated subaddresses, it would achieve nothing but bloat.

Ok, thanks, thought so

6197 should fix this.

good question. will a tx file created by a new wallet release be able to be signed by an older release?

Depends whether the format has changed. To preempt the next question: about the recent release, I don't know whether it did.

gingeropolous: seems like a stupid question though. why wouldn't you just run the same new version on both the tx creator and the tx signer?

If exchnaging multisig txes, the keys might be controlled by several parties who do not update at the same time. Corner case I guess, yes.

Oh, I read the link. That is indeed annoying if you intend to never connect the cold wallet. That is basically impossible.

For now anyway. The current release can't grok ommiring/lelantus/whatever we'll use later, so cannot sign them.

For as long as we improve the tx protocol, this cannot be done.