From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id D633A46D1B for ; Sun, 9 Jul 2023 16:26:51 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2745968C581; Sun, 9 Jul 2023 19:26:48 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3003468C397 for ; Sun, 9 Jul 2023 19:26:41 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id F2AF2E8B97 for ; Sun, 9 Jul 2023 18:23:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXvSbGcI6wPs for ; Sun, 9 Jul 2023 18:23:30 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id E134AE6816 for ; Sun, 9 Jul 2023 18:23:29 +0200 (CEST) Date: Sun, 9 Jul 2023 18:23:29 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <168889665180.542.9354129396884912818@lain.khirnov.net> Message-ID: <67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu> References: <20230707102136.16235-1-anton@khirnov.net> <6659e86-e959-9c42-ba13-8e1da890c46@passwd.hu> <168889665180.542.9354129396884912818@lain.khirnov.net> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] lavu/random_seed: use getrandom() when available X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Sun, 9 Jul 2023, Anton Khirnov wrote: > Quoting Marton Balint (2023-07-07 22:02:26) >> >> >> On Fri, 7 Jul 2023, Anton Khirnov wrote: >> >>> It is a better interface for /dev/u?random on Linux, which avoids the >>> issues associated with opening files. >> >> >> getrandom() actually have the same problem as read(). It can read less >> than requested. So you should use it in a loop in that case or if it >> returns EINTR. > > I'm not convinced it's actually a problem. > > This API is intended for small secrets like keys and such, somebody > trying to generate vast quantities of random data is likely misusing it > and could just as well use LFG or something. > > Failing in that case seems like a good thing to me. This is a very bad argument. If the API should not be used for big secrets, then it should always fail for size > 256 or something, not sometimes fail. And such limitation should be documented. And its not just about big secrets. EINTR can be returned for small secrets as well, and you should handle it. I also question if it is a good idea to use the non blocking mode. Imagine a situation when somebody wants to automatically start a command line after boot which needs a key. It might fail right after boot, but will work after a couple of minutes. IMHO it is better to block (1-2 minute tops) than making the function sometimes work, sometimes not. Regards, Marton _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".