search for: coveyou

...and mips with current toolchains. Are you still intending to make further releases of klibc? Would you be willing to add co-maintainers? Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <http://www.zytor.com/pipermail/klibc/attachments/20181230/ceea6db7/attachment.sig>

...y, but I was not able to do it. I have also spent quite a lot time looking in the internet for similar issues, but found nothing helpful. any suggestions? thanks -Francesco Stablum P.S. sorry for my poor english -- The generation of random numbers is too important to be left to chance - Robert R. Coveyou

...>> I don't think the OpenSSH devels really do care about that - there is no discussion whatsoever on the secureshell list or on the devel list. No idea about our upstream, but I don't think so either. << Correct: all that needs to be said was said years ago, by Dr. Robert E. Coveyou, of Oak Ridge National Laboratory (now NIST): "The generation of random numbers is to important to be left to chance". Best, --- Les Bell, RHCE, CISSP [http://www.lesbell.com.au] Tel: +61 2 9451 1144 FreeWorldDialup: 800909

...ink that if we can *cheaply* implement a glibc API that allows more software to build and run on klibc with fewer changes, then we should. Ben. -- Ben Hutchings The generation of random numbers is too important to be left to chance. - Robert Coveyou -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: <https://lists.zytor.com/archives/klibc/attachments/20200728/89607ba8/attachment.sig>

On Saturday, 25 July 2020, 23:36:33 CEST, Ben Hutchings wrote: > On Wed, 2020-07-08 at 08:37 +0200, Christian Eggers wrote: > > ... > > libkeyutils usually invokes syscall() directly. As syscall() is not > > provided by klibc, libkeyutils has to be slightly modified for using the > > klibc wrappers. > > Wouldn't it be more useful for klibc to implement