can sc_reduce32 return 0?

hello

recommend node js library to talk to monero node please

most libraries ive googled seem to be vulnrable

huh? what does nodejs library have to do with this khayrullo? this would indicate that these wallet projects just need to improve their implementation of running the local wallet RPC process

these projects are super old anyways...

wouldn't the right recommendation be to run the monero wallet RPC with at least authentication? and at most with full DNS and TLS cert setup?

wouldn't the attacker have to guess the right amount, too? it will fail to send the TX if it's more funds than are available

are there any v0.15.0.5 reproducible builds available?

^ hyc: iDunk: selsta: or anybody else doing reproducible builds

xiphon: gui.xmr.pm/files/cli/v0.15.0.5

but they are also on getmonero.org

thanks

xiphon: are you looking at the glibc issue? we used a newer gcc version, I guess that’s the problem

"we used a newer gcc version" -> it won't affect glibc version

i would say that reproducible builds doesn't support anything older Ubuntu bionic 18.04

weird that no one complained until now

xiphon: ok, people are reporting that v0.15.0.1 works on Ubuntu 16.04, the only thing we changed is newer gcc and updated libsodium

selsta: yeah, my bad - apparently inspecting the binaries i misread `gnu_get_libc_version@@GLIBC_2.2.5` as `GLIBC_2.25`

libsodium 1.0.18 uses getrandom(...) which is availabe only since glibc 2.25

Some PRs that require (final) review or approval (after rebase), would appreciate if people could have a look

Needs review:

6269 6296 6298 6304

Needs final approval (after rebase):

6227 6260

Needs final review:

6214 6278 6299

selsta: could you do linux x64 reproducible build with monero-project/monero #6397 ?

I can do a depends build which should be equal.

That... prevents building if you're using an old glibc ?

I don’t know how to do a reproduce build only for 1 platform.

moneromooo: it prevents invoking these functions, i would expect libsodium will use some workaround then

like getrandom syscall

selsta: "I can do a depends build which should be equal" <- sounds good

So this is making configure think there is no getrandom call. It looks like purposefully undermining random quality, no ?

Then again we're using /dev directly. Any places we use sodium random ?

"It looks like purposefully undermining random quality, no ?" -> nope, why do you think so?

Because if a configure test fails, I expect it won't be using that symbol.

That's usually what those tests are used for anyway.

What is this intended to do anyway ?

"Then again we're using /dev directly. Any places we use sodium random ?" -> will have a look, maybe we can drop the code using sodium random

"What is this intended to do anyway ?" -> to not link agains getrandom/getentropy that require glibc 2.25

and let monero wallet binaries run on Ubuntu 16.04, for example

OK, still seems like a landmine if we end up using libsodium's random later, we'd need to not forget to undo that...

yep, would be better just drop fairly outdated OSes support

Well 16.04 is still supported because it's LTS

i know

moneromooo: "OK, still seems like a landmine if we end up using libsodium's random later" -> we can integrate a check in to build process

the check will get the glibc version required by resulted monero binaries and fail if it is greater than the version we want

^ if we follow the way of dropping the code that uses sodium random, of course

Inspected the code

Libsodium uses getrandom() during initialization

No way we can drop this, once you call sodium_init(), it will initialize its entropy buffers and invoke getrandom() (if it is available)

building your patch now xiphon

TheCharlatan: sounds good, let me know the results

Left one more comment on the pr xiphon. With that done, I have verified that getrandom is no longer in the symbol table. Should obv. test creating a wallet etc.

xiphon: do you still need the build?

selsta: nope, seems TheCharlatan already checked the patch

oki