04:43:17 <br-m> <321bob321> Docker build —no-cache
14:04:19 <br-m> <rbrunner7> Is the result of wipeable_string.data null terminated? I would guess "no".
14:09:39 <br-m> <rbrunner7> If not, and I have to hand the content of a wipeable string to a method accepting a null-terminated char*, how do I solve this problem without making some copy that would totally undermine the effect of the wiping?
14:12:32 <moneromooo> I just looked, it is not indeed. Just add a 0 ?
14:12:59 <br-m> <rbrunner7> To the content of the wipeable string then?
14:13:01 <moneromooo> ie, s.push_back(char(0));
14:13:05 <moneromooo> Yes.
14:14:10 <br-m> <rbrunner7> Hmm. I can try. It's a seed that's in the wipeable string. I hope that 0 does not disturb the processing of the seed. (I need the 0 only if it's a Polyseed.)
14:14:11 <moneromooo> The function you call it on might be doing some copying itself, fwiw.
14:14:32 <moneromooo> Well, pop it later, or pass a copy with the extra 0.
14:15:09 <br-m> <rbrunner7> Alright. Yes, the first thing that the Polyseed method does is splitting the seed into an array :)
14:15:24 <moneromooo> Then you're fucked ^_^
14:16:11 <moneromooo> Or you could try patching that lib to cleanup if it doesn't, since you seem to have the source.
14:16:47 <br-m> <rbrunner7> Yeah, that "wipeable string for seed variables" seems to be a bit of a show without real effect, at least in the CLI wallet
14:18:06 <moneromooo> er, no. I specifically used C funcs to avoid the usual C++ stuff buffering copies.
14:18:28 <moneromooo> And I checked the RAM image to make sure nothing was left.
14:19:27 <br-m> <rbrunner7> So you think that the method that converts the "legacy" 25 word seeds into a private key does not leave enough traces in RAM to puzzle together the full seed again?
14:20:32 <moneromooo> I have only vague memories of that part tbh. I could not tell you for sure.
14:20:52 <br-m> <rbrunner7> Alright, thanks
14:20:58 <moneromooo> I do remember trying to wipe stuff. I might have missed some.
14:21:32 <br-m> <rbrunner7> The CLI wallet code itself looks indeed clean
14:21:57 <moneromooo> The words are easy to search for, but an encoded integer from them is less so.
14:22:22 <moneromooo> In any case, there is a memwipe function to wipe stuff that's not automagic.
14:23:07 <br-m> <rbrunner7> Ah, good idea.
14:23:27 <moneromooo> I remembering having a funny time writing a test for it.
14:24:22 <moneromooo> The compiler would moan at me a lot there, trying to read freed stuff, and yes I ACTUALLY MEAN IT YOU TWAT.
14:24:48 <moneromooo> Never sure what code will generate there since UB.
14:25:14 <moneromooo> Oh, maybe I should have written my own allocator. Stupid cow.
14:25:22 <br-m> <rbrunner7> Those were the times :)
14:25:47 <moneromooo> Well, there you go. I think of it in twenty seconds now, not back then.
14:26:38 <moneromooo> Though a custom allocator might well change the generated code wrt that, so...
14:28:05 <br-m> <rbrunner7> This might be a game that you can't really win
14:31:10 <br-m> <jpk68:matrix.org> selsta: What do you think of using the greatest two units for the human-readable logging thing? For example, just "2 weeks, 4 days" instead of all the smaller ones
14:31:25 <br-m> <jpk68:matrix.org> I also propose just removing the month unit because it's confusing
14:32:06 <selsta> I would look where it's used first, like does it ever print time frames that would be weeks?
14:32:47 <br-m> <jpk68:matrix.org> Well, if your node is running for weeks, then print_net_stats does
14:33:56 <br-m> <ofrnxmr:xmr.mx> Nack
14:34:32 <br-m> <ofrnxmr:xmr.mx> 164 days is more usabke than doing math to figure out how many days 12 weeks + 6 days is
14:34:43 <br-m> <jpk68:matrix.org> Sounds like it's more trouble than it's worth. I can close it
16:34:08 <scoobybejesus> https://secpaste.dev/show/pgTjqz8R  Started by editing dockrun.sh to have the two docker build lines start with docker build --no-cache. Then wiped out the containers/images again to start from scratch.  Now I get ubuntu@sha256:152dc042452...  Perfect.  Yet the i686-linux hash still doesn't work.  I'm happy to get the host up to 24.04 or even 26.04
16:34:08 <scoobybejesus> LTS. Or I'm happy to try something different if there's curiosity about what's going on.  Let me know if I should PR this round, or upload the build log and bz2 file again, or whatever.
16:37:29 <br-m> <ofrnxmr:xmr.mx> Comment out the cache line in the dockerfiles in gitian/docker folder
16:37:39 <br-m> <ofrnxmr:xmr.mx> I have RUN echo 'Acquire::http { Proxy "http://172.17.0.1:3142"; };' > /etc/apt/apt.conf.d/50cacher commented out in the files in the docker folder
16:37:39 <br-m> <ofrnxmr:xmr.mx> https://github.com/monero-project/monero/blob/release-v0.18/contrib%2Fgitian%2Fdockrun.sh#L31-L79
16:39:41 <br-m> <ofrnxmr:xmr.mx> I think its possibly apt-cache-ng that is the difference
16:39:55 <br-m> <ofrnxmr:xmr.mx> Debian doesnt have it, gitian-build.py doesnt use it
16:40:09 <br-m> <ofrnxmr:xmr.mx> Its only in dockrun iirc.
16:40:26 <scoobybejesus> I will try that without rm'ing anything.  SOunds good
16:41:14 <br-m> <ofrnxmr:xmr.mx> You might still have to delete the containers, since its already existing in them
16:43:27 <scoobybejesus> Ah, i see what you mean, yes
17:42:52 <scoobybejesus> Commented out those RUN echo 'Acquire.. lines in dockrun.sh.  rm'd everything, and started fresh.  i686 hash is still b6fad27181d0...  Anything else I should do/try before dist-upgrade'ing to 24.04 LTS or 26.04 LTS?
17:45:20 <br-m> <ofrnxmr:xmr.mx> Can just try running it in a vm?
17:46:05 <br-m> <ofrnxmr:xmr.mx> im almost about to install a 22.04 vm and try it ..
17:55:43 <scoobybejesus> Not opposed, but can't do that right now.  Don't have any Linux vm's going. I can find some kvm write-up later
18:03:49 <br-m> <jpk68:matrix.org> Which would be the preferred way to do Base32 {en,de}coding? It seems Boost iterator chains could work, or just copying an existing implementation
19:14:21 <br-m> <rbrunner7> Way back, in 2024, when we still thought that we will go for Seraphis and Jamtis, @jeffro256:monero.social implemented this: https://github.com/seraphis-migration/monero/commit/b071e2c099fc73882ea10913b5693d30443791e6
19:15:17 <br-m> <rbrunner7> It's geared towards Jamtis however, as far as I remember, with a special character set used
19:15:34 <br-m> <jpk68:matrix.org> Makes sense. Thanks for the link
19:22:02 <tevador> Note that for Jamtis-PQ, I'm specifying that bits are decoded from the LSB of each byte rather than MSB (so it effectively does a modulo operation on a little-endian integer).
20:10:00 <br-m> <jpk68:matrix.org> Does anyone have any idea as to why I'm getting a linking error when attempting to use ge_frombytes_vartime from src/net/?
20:10:11 <br-m> <jpk68:matrix.org> I included crypto/crypto-ops.h and linked cncrypto in the CMake file for net/
20:12:00 <br-m> <vtnerd> If your including crypto-ops.h from a c++ file, the problem is c for c++ linkabe
20:12:13 <br-m> <vtnerd> *linkage
20:12:45 <br-m> <vtnerd> The header file for crypto-ops.h doesn't check for c++ compilation and switch to c linkage
20:12:57 <br-m> <vtnerd> *doesn't switch to
20:14:18 <br-m> <jpk68:matrix.org> Does it have to be used from a C source file/header then?
20:15:34 <br-m> <vtnerd> Just Google it, you have to use a special designator when including the header. See crypto.h with the random.h include as a crude example
20:15:49 <br-m> <jpk68:matrix.org> My bad, thank you
20:16:23 <br-m> <jpk68:matrix.org> I was somehow unaware that was even a thing
20:16:52 <br-m> <vtnerd> Yes, it's non obvious unless you're reading abi spec sheets
22:03:31 <tobtoht> scoobybejesus: Can you update your PR again? I want to check the assert files.
22:19:27 <scoobybejesus> I guess shell expansion doesn't work inside single quotes. Anyway, pushed, tobtoht 
22:33:41 <tobtoht> scoobybejesus: your build environment didn't change again.. what the heck
22:36:39 <scoobybejesus> I have a few other docker containers running.  They never posed an issue before.  I'd like to think they are all independent anyway.  I dunno.  
22:37:10 <selsta> that's why I don't touch docker :D
22:37:33 <selsta> outside a vm
22:38:50 <scoobybejesus> it's tempting to nuke all the docker stuff.  only one container is "needed", and I can add that back later, easy peasy
22:39:54 <scoobybejesus> then again, it's also tempting to get up to 24.04 and see if that solves it... which doesn't make sense to me either..  though docker hides enough complexity that i don't know exactly what goes on under the hood
22:40:59 <scoobybejesus> it's tempting to offer a shared tmux session, but ...  i dunno :)
23:05:56 <tobtoht> it would make the most sense for the reproducibility issue to be caused by the large number of extra packages present in your build container
23:06:04 <tobtoht> i don't know why docker keeps spitting out the same environment.. another cache somewhere?
23:06:15 <tobtoht> if the reproducibility issue is caused by something else, I want to get to the bottom of it
23:06:25 <tobtoht> but we need a matching build environment first...
23:31:57 <tobtoht> using a reproducibility issue on an unimportant target (e.g. i686 linux) to get all builders to use fresh (malicious) images is exactly how i would expect someone to attempt to backdoor our gitian builds
23:32:23 <tobtoht> lay dormant on the important targets for one or two release cycles and insert dummy non-determinism on the unimportant target the first time around
23:32:38 <tobtoht> that's not what happened here because scooby's env only contains additional packages
23:33:01 <tobtoht> still, gitian makes no attempt to pin the env, so we're placing a lot of trust in ubuntu('s servers)
23:33:29 <tobtoht> can't wait for guix on the release branch
23:33:53 <scoobybejesus> i just stopped every container (but the one "important" one), deleted all those containers, and deleted all their images.  running dockrun again...
23:49:26 <tobtoht> scoobybejesus: did you docker image prune --all ?
23:50:08 <scoobybejesus> this time, no.  shall i stop and do that to ensure it's all gone?
23:50:32 <tobtoht> it would increase our chances of success i think
23:51:22 <tobtoht> make sure to delete the gitian containers first
23:59:51 <scoobybejesus> okay, also just did docker builder prune -a to get rid of all that cache.  sheesh