<321bob321> Docker build —no-cache

<rbrunner7> Is the result of wipeable_string.data null terminated? I would guess "no".

<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?

I just looked, it is not indeed. Just add a 0 ?

<rbrunner7> To the content of the wipeable string then?

ie, s.push_back(char(0));

Yes.

<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.)

The function you call it on might be doing some copying itself, fwiw.

Well, pop it later, or pass a copy with the extra 0.

<rbrunner7> Alright. Yes, the first thing that the Polyseed method does is splitting the seed into an array :)

Then you're fucked ^_^

Or you could try patching that lib to cleanup if it doesn't, since you seem to have the source.

<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

er, no. I specifically used C funcs to avoid the usual C++ stuff buffering copies.

And I checked the RAM image to make sure nothing was left.

<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?

I have only vague memories of that part tbh. I could not tell you for sure.

<rbrunner7> Alright, thanks

I do remember trying to wipe stuff. I might have missed some.

<rbrunner7> The CLI wallet code itself looks indeed clean

The words are easy to search for, but an encoded integer from them is less so.

In any case, there is a memwipe function to wipe stuff that's not automagic.

<rbrunner7> Ah, good idea.

I remembering having a funny time writing a test for it.

The compiler would moan at me a lot there, trying to read freed stuff, and yes I ACTUALLY MEAN IT YOU TWAT.

Never sure what code will generate there since UB.

Oh, maybe I should have written my own allocator. Stupid cow.

<rbrunner7> Those were the times :)

Well, there you go. I think of it in twenty seconds now, not back then.

Though a custom allocator might well change the generated code wrt that, so...

<rbrunner7> This might be a game that you can't really win

<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

<jpk68:matrix.org> I also propose just removing the month unit because it's confusing

I would look where it's used first, like does it ever print time frames that would be weeks?

<jpk68:matrix.org> Well, if your node is running for weeks, then print_net_stats does

<ofrnxmr:xmr.mx> Nack

<ofrnxmr:xmr.mx> 164 days is more usabke than doing math to figure out how many days 12 weeks + 6 days is

<jpk68:matrix.org> Sounds like it's more trouble than it's worth. I can close it

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

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.

<ofrnxmr:xmr.mx> Comment out the cache line in the dockerfiles in gitian/docker folder

<ofrnxmr:xmr.mx> I have RUN echo 'Acquire::http { Proxy "172.17.0.1:3142"; };' > /etc/apt/apt.conf.d/50cacher commented out in the files in the docker folder

<ofrnxmr:xmr.mx> github.com/monero-project/monero/bl…ntrib%2Fgitian%2Fdockrun.sh#L31-L79

<ofrnxmr:xmr.mx> I think its possibly apt-cache-ng that is the difference

<ofrnxmr:xmr.mx> Debian doesnt have it, gitian-build.py doesnt use it

<ofrnxmr:xmr.mx> Its only in dockrun iirc.

I will try that without rm'ing anything. SOunds good

<ofrnxmr:xmr.mx> You might still have to delete the containers, since its already existing in them

Ah, i see what you mean, yes

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?

<ofrnxmr:xmr.mx> Can just try running it in a vm?

<ofrnxmr:xmr.mx> im almost about to install a 22.04 vm and try it ..

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

<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

<rbrunner7> Way back, in 2024, when we still thought that we will go for Seraphis and Jamtis, @jeffro256:monero.social implemented this: seraphis-migration/monero b071e2c

<rbrunner7> It's geared towards Jamtis however, as far as I remember, with a special character set used

<jpk68:matrix.org> Makes sense. Thanks for the link

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).

<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/?

<jpk68:matrix.org> I included crypto/crypto-ops.h and linked cncrypto in the CMake file for net/

<vtnerd> If your including crypto-ops.h from a c++ file, the problem is c for c++ linkabe

<vtnerd> *linkage

<vtnerd> The header file for crypto-ops.h doesn't check for c++ compilation and switch to c linkage

<vtnerd> *doesn't switch to

<jpk68:matrix.org> Does it have to be used from a C source file/header then?

<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

<jpk68:matrix.org> My bad, thank you

<jpk68:matrix.org> I was somehow unaware that was even a thing

<vtnerd> Yes, it's non obvious unless you're reading abi spec sheets

scoobybejesus: Can you update your PR again? I want to check the assert files.

I guess shell expansion doesn't work inside single quotes. Anyway, pushed, tobtoht

scoobybejesus: your build environment didn't change again.. what the heck

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.

that's why I don't touch docker :D

outside a vm

it's tempting to nuke all the docker stuff. only one container is "needed", and I can add that back later, easy peasy

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

it's tempting to offer a shared tmux session, but ... i dunno :)

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

i don't know why docker keeps spitting out the same environment.. another cache somewhere?

if the reproducibility issue is caused by something else, I want to get to the bottom of it

but we need a matching build environment first...

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

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

that's not what happened here because scooby's env only contains additional packages

still, gitian makes no attempt to pin the env, so we're placing a lot of trust in ubuntu('s servers)

can't wait for guix on the release branch

i just stopped every container (but the one "important" one), deleted all those containers, and deleted all their images. running dockrun again...

scoobybejesus: did you docker image prune --all ?

this time, no. shall i stop and do that to ensure it's all gone?

it would increase our chances of success i think

make sure to delete the gitian containers first

okay, also just did docker builder prune -a to get rid of all that cache. sheesh