Dear Gui-Ye, > I have already tried increasing the parameter following ulimit -s to > 13200, but it still triggered a segmentation fault. The crucial buildd > log is here:
looking at that log, this segfault occurs after the peers getting their initial parameters, exactly when they try to allocate the memory for all the state needed during the rest of the protocol. so somewhere here: https://github.com/stef/liboprf/blob/master/src/tests/tp-dkg.c#L426-L465 and this is all stuff were (a lot) memory is allocated on the stack. and normally if you allocate too much, you get a segfault. this is normal, and not really a problem, this is by design. however the symptom looks quite like something insecure, which is unfortunate. i suppose there is a hardlimit on the size of the stack? could you do ulimit -Ss and ulimit -Hs the latter might be smaller than the 13200 we provide? if this is not the case, i would love to test this on a live system, maybe i can setup a riscv qemu instance with exactly the same debian environment in which this fails. would you be able to tell me the exact riscv arch and debian version i need for this to reproduce? or do you think if i get one of these, i these systems have already the correct environment for me? https://dsa.debian.org/doc/guest-account/ thx,s
