03:13:25 <maxwilliamson> hey devs, any plans to digital sign the packages?
03:24:37 <hyc> PGP sign?
03:25:08 <hyc> how is that more effective than signing the hashes?
06:09:06 <Flenst> does rpc_access_tracking only track rpc access through the new payment system? called it, and got 404/empty as response
07:10:51 <maxwilliamson> hyc: not PGP, but with a code signing certificate
07:12:24 <maxwilliamson> it's like 60 bucks a year, dead cheap
07:14:05 <maxwilliamson> and it will provide security, because 70% don't verify hashes when downloading and running stuff
07:28:18 <selsta> maxwilliamson: what OS?
07:29:35 <selsta> Is this code signing certificate for Windows? Because there is a separate one for macOS and probably no such thing for Linux.
07:49:28 <rbrunner> 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
07:49:58 <rbrunner> Anyway, how many people will know that the code *must* be signed and really do not install if it's missing?
07:50:31 <rbrunner> 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?
07:50:52 <rbrunner> And yes, as selsta said, probably Windows-only solution anyway, so less than ideal
09:13:44 <maxwilliamson> Yeah, and people use windows *a lot*
09:14:47 <maxwilliamson> https://codesigncert.com/
09:16:10 <maxwilliamson> pretty cheap for security it will offer
09:20:00 <maxwilliamson> A lot of people actually check for code signatures because windows warns when the program is not signed.
09:52:08 <rbrunner> 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.
09:52:45 <rbrunner> 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
09:53:39 <rbrunner> By the way, I also see the non-trivial question of who would be the owner of the certificate
10:05:27 <selsta> Also how does a certificate work together with reproducible builds?
10:11:10 <rbrunner> 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
10:11:48 <rbrunner> But I can't deny that quite in general a valid signature there would at least *look* good, make a good impression
10:12:11 <rbrunner> "Signed by MEA"
10:12:24 <rbrunner> For people who remember that :)
10:13:14 <sech1> It has to be a real organisation/person to get code signing certificate.
10:13:45 <rbrunner> Yes, I think so, and that would probably be "non-trivial" to agree on somebody / something
10:14:35 <rbrunner> And to found something just for that is probably overkill
10:15:58 <maxwilliamson> rbrunner: many programs are indeed signed and people notice that.
10:16:54 <maxwilliamson> selsta: just code sign the installer. don't sign things that needs to be reproduced.
10:17:02 <rbrunner> 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
10:18:17 <rbrunner> 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 :(
10:18:37 <rbrunner> Installer builds are reproducible
10:19:02 <selsta> rbrunner: GUI is not reproducible
10:19:47 <rbrunner> 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?
10:20:43 <maxwilliamson> at least tor code signs and still has reproducible builds
10:21:16 <maxwilliamson> nvm, doesn't affect me. don't want to waste energy on this
10:21:21 <rbrunner> https://old.reddit.com/r/Monero/comments/cd0snl/help_test_reproducible_windows_gui_installer/
10:25:11 <selsta> rbrunner: No, first we migrate to cmake and then we try to make it reproducible :P
10:25:40 <rbrunner> Ok. At least there is hope
10:26:21 <selsta> I’ve been looking into notarizing the macOS builds, which is a step before signing I think.
10:28:05 <rbrunner> maxwilliamson: Do you know of a good explanation how Tor does that, sign code *and* having reproducible builds?
10:28:52 <rbrunner> As certainly only the key owner can sign, how other people can reproduce? Maybe I overlook something.
10:36:18 <sech1> 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.
10:38:01 <rbrunner> 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?
10:39:39 <rbrunner> Untrustworthy in principle only of course, because non-reproducible
10:39:45 <rbrunner> It's signed after all
11:33:02 <jonathancross> In bitcoin, you'll see separate sigs for signed / unsigned builds:
11:33:02 <jonathancross> https://github.com/bitcoin-core/gitian.sigs?files=1
11:36:35 <jonathancross> > Ok. At least there is hope
11:36:35 <jonathancross> 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 :-)
12:51:36 <gingeropolous> make release-static just barfed all over me
12:51:38 <gingeropolous> https://paste.fedoraproject.org/paste/~cbTSI-TixXw8dAs6BuRQw
13:58:43 <rbrunner> What do people think about the following idea of mine: While syncing make the daemon periodically display time estimates until fully synced
13:58:56 <rbrunner> 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.
13:59:07 <rbrunner> Thus (hopefully) also being able to give useful total estimates for syncing from scratch
13:59:17 <rbrunner> Maybe make the estimates also available through daemon RPC so wallets could display them to users if they so wish
13:59:29 <rbrunner> I could see me implementing that over the next few weeks
14:00:05 <gingeropolous> yeah, sounds nice. would be great for gui
14:02:40 <moneromooo> That was a pretty low priority thing I wanted to do. I'd totally ACK it if decent.
14:03:27 <rbrunner> Puh. Lucky me that you didn't do that already then :)
14:04:08 <rbrunner> 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
14:05:13 <moneromooo> What might also be nice, and possibly a byproduct of this, would be to determine what is the bottleneck.
14:05:40 <moneromooo> "You know, it'd go faster if you had a faster $THINGIE"
14:06:42 <moneromooo> Noting that currently, sync is often still waiting for blocks to arrive.
14:07:09 <moneromooo> Maybe less so now that you can set the span download cache size though.
14:08:21 <rbrunner> I see.
14:12:38 <rbrunner> 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
14:25:53 <moneromooo> Testnet will likely give you PoW performance.
14:26:34 <moneromooo> Hmm. Actually, I take that back. I'm not sure it will...
17:04:31 <binaryFate> would be nice to be able to bundle 'set' commands in one line, or in a copy/paste friendly manner.
17:05:43 <binaryFate> 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.
17:06:32 <binaryFate> What would be the intuitive syntax for this? Semi-colon? "set <command_1>; <command_2>; ..."
17:06:43 <moneromooo> "monero-wallet-cli --wallet-file foo set foo bar ?
17:07:37 <moneromooo> Oh, you want a single line, rather than two set commands ?
17:07:56 <moneromooo> You can paste stuff with a newline in it, right ?
17:08:10 <moneromooo> Or does that not work ?
17:08:45 <binaryFate> Can paste stuff with newline but it asks for password for each of them
17:10:20 <nonie> does the config file support set?
17:13:15 <binaryFate> "monero-wallet-cli --wallet-file foo set foo bar" is nice, but I can't put two different set commands in there I think?
17:13:45 <binaryFate> like "monero-wallet-cli --wallet-file foo set foo bar set foo2 bar2" does not seem to do anything about the second set command
17:20:57 <TheCharlatan> 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
17:20:59 <TheCharlatan> the build is done, thus preserving reproducibility.
17:26:36 <gingeropolous> 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: https://paste.fedoraproject.org/paste/lAxqeiFavDlHWnHpnsL2sQ
17:30:45 <gingeropolous> hrm, found it
17:31:08 <gingeropolous> 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
17:31:24 <gingeropolous> so it seems to want the --restricted-rpc flag, not the one that specifies the port
17:48:15 <gingeropolous> hrmmm.. we lost the whole up arrow to repeat command thing?
17:48:56 <iDunk> Is that with your static build ?
17:49:18 <iDunk> Btw, did you solve the libusb-1.0.a thing ?
17:50:24 <gingeropolous> no, i just compiled regular.
17:50:28 <gingeropolous> instead of static
17:50:39 <iDunk> Command history works here.
17:50:47 <iDunk> dpkg -S libusb-1.0.a | sed s/\:.*// | xargs dpkg --get-selections
17:57:34 <binaryFate> 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"
17:58:08 <gingeropolous> did it have an encrypted payment id?
17:58:09 <binaryFate> I am 100% sure there was no encrypted payment ID. Is the detection of encrypted payment ID or not based on a heuristic or?...
18:01:26 <gingeropolous> huh, static just built fine iDunk . mystery
18:01:47 <iDunk> It did here as well.
18:02:29 <gingeropolous> rpc payment is working fine for me, at least on cli
18:13:30 <gingeropolous> welp, no rpc payment functionality in the GUI
18:20:38 <dEBRUYNE> binaryFate: Each transaction now has an encrypted payment ID attached
18:20:42 <dEBRUYNE> Regardless of whether you specified it
18:38:27 <luigi1111> maybe consider removing that warning? seems meh
18:44:02 <rbrunner>  Each transaction now has an encrypted payment ID attached <- Also the ones to subaddresses, which then would also trigger the warning?
18:44:12 <rbrunner> Really seems like some false alarm to me
18:44:53 <dEBRUYNE> That I am not sure of
18:46:01 <rbrunner> Well, without that txs to subaddresses would stand out, which would surprise me immensely
18:46:58 <binaryFate> Oh ok, I hadn't noticed before. This does not make sense to warn user about doing X if he did not do X.
18:46:58 <rbrunner> Let's continue to speculate until moneromooo spoils all the fun with facts :)
18:47:54 <rbrunner> And maybe recommending Y which then would result in the very same warning ...
18:48:03 <binaryFate> <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?
18:49:04 <rbrunner> From the point when the feature with random payment IDs started. I assume every tx gets one, whether to address or subaddress
18:49:48 <dEBRUYNE> Think this was implemented last HF
18:51:11 <rbrunner> I think I saw that warning about 2 weeks ago for the first time.
18:51:50 <rbrunner> Not reporting it, assuming it will get corrected quickly
18:52:17 <rbrunner> Maybe that non-reporting was not so clever ...
18:52:39 <binaryFate> it was reported, even on reddit
18:53:09 <binaryFate> there was nothing new, just a misunderstanding of many people who did not follow previous discussions about subaddresses closely enough (including me)
18:54:00 <rbrunner> You mean the preference? To nudge people now towards subaddresses?
18:54:15 <dEBRUYNE> rbrunner: As far as I can see, the warning is new, an encrypted pID being added for each transaction is not
18:54:49 <rbrunner> Sounds right
18:57:55 <binaryFate> I mean that you can distinguish transfers to subaddresses or non-subaddresses
19:37:29 <moneromooo> Speculate about... ?
19:38:22 <moneromooo> Payments to a standard address that don't have payment id get a dummy short one.
19:38:32 <moneromooo> Sending to subaddresses don't.
19:39:09 <moneromooo> About the warning, maybe I did not PR something, IIRC it's supposed to warn for a non zero one only.
19:40:27 <moneromooo> Well, it... compares without decrypting. That's why it triggers when it should not. Easy to fix.
19:41:01 <rbrunner> Pardon my ignorance - why not just slap a dummy short one on transfers to subaddresses also, so they blend in as well?
19:41:52 <rbrunner> Or are subaddress transfers already recognizable for other reasons, so that would be pointless?
19:42:57 <moneromooo> There are no integrated subaddresses.
19:45:02 <rbrunner> Right. I was thinking on a more technical, data-structure level. Do I remember correctly - encrypted payment ids go into txextra?
19:45:16 <rbrunner> Or were the unencrypted ones?
19:45:33 <moneromooo> Both.
19:45:59 <rbrunner> So you could put one into txextra also for a transfer to a subaddress?
19:47:17 <rbrunner> Just to make it not stand out - on that low level.
19:48:17 <rbrunner> But I am sure the problem is my lack of detail knowledge, that must not be possible somehow, otherwise we would do it already
19:49:43 <moneromooo> Eve can tell which outputs are to a subaddress. Currently anyway. So since there are no integrated subaddresses, it would achieve nothing but bloat.
19:50:20 <rbrunner> Ok, thanks, thought so
20:09:38 <moneromooo> 6197 should fix this.
21:45:03 <gingeropolous> https://www.reddit.com/r/Monero/comments/e3l3so/a_feature_request_for_all_future_monero_releases/f93nqnc/?context=3
21:46:08 <gingeropolous> good question. will a tx file created by a new wallet release be able to be signed by an older release?
21:47:57 <moneromooo> Depends whether the format has changed. To preempt the next question: about the recent release, I don't know whether it did.
22:23:33 <hyc> 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?
22:53:49 <moneromooo> 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.
23:19:45 <moneromooo> Oh, I read the link. That is indeed annoying if you intend to never connect the cold wallet. That is basically impossible.
23:20:21 <moneromooo> For now anyway. The current release can't grok ommiring/lelantus/whatever we'll use later, so cannot sign them.
23:20:39 <moneromooo> For as long as we improve the tx protocol, this cannot be done.