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 4B19446D1E for ; Sun, 9 Jul 2023 16:30:27 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7B9B068C62D; Sun, 9 Jul 2023 19:30:25 +0300 (EEST) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 29BD968C1EC for ; Sun, 9 Jul 2023 19:30:19 +0300 (EEST) Received: by mail-ot1-f47.google.com with SMTP id 46e09a7af769-6b5f362f4beso3319473a34.2 for ; Sun, 09 Jul 2023 09:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688920217; x=1691512217; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=i8c/NKuyaNGCZojW/dJA4uEwgd4xRu6jEqJAE158Eqs=; b=S3v1rFz2+2gLP1tKvghtiGok653deLBxxal2LyEHYNhVuhWKXdRKyrOc7ZTQ9MCyhx 3VRfH7yRVw6Qe4BdWxTFrnROiuQZkzab4qd7ZkrRSta6nt/fSObqqp5OJ2hALJ1gzhzv NeqWwJvNofSdtY/S/eRLHB5xOm5Uuqw1Pg+ah3e4JbpSz+LcN25Z2XexTFtYGWZM7PQh eOzOvAgutliKRdq4SjiR7TZfKx137xkU3VWrsokx5hDRoDTCtHf0pEIRgl2MssBd6z6w 8Bag+nbGiL6Tjeb4wYBtOBb9di6UnpALHOUrQEk9QQu+Cl6StEm+2icQfRd48GNZyK4J DEtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688920217; x=1691512217; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i8c/NKuyaNGCZojW/dJA4uEwgd4xRu6jEqJAE158Eqs=; b=UAxwgvcjM7PaJPG5uWJmzVyofYbYbGnN2GpOTFQGN7YJ9Bvywt/xGNFTqgVf1AG2/p IcSXzHbr6WxpOJCdo1MY1k4VjsY4bZq5yjHX5zSqPRBgOVxIlFf16XtI16cDfKDdNtEs O9I3K6GFJT0gb73EQgHIG29j/HyNprwhx+/pXNypF69Zwhvf/R323ou7IbhE2FUiI17v QYuLYQG73lq7CPEIntqymZmWS0lhfQAT1LNycKJlPDuq96q004o891KEbcAWahdNjEeK rTn4oDkcDI503spUuTQTlNn8WPFJzdqMT0lPmU1fTcRArEq4Ij++WGhfzFSkeImC239Q K5Gw== X-Gm-Message-State: ABy/qLb2PMqSvRPG4nM7NHxC3/Uem6/GoD/SvcQfiBCzpZLm4ni2HiaC htbDUv/Qyz6t2VoW3C8veHvHzzWiP8U= X-Google-Smtp-Source: APBJJlFmUzlkP1QgFjBqV1B3sVOzUXa9OMTvsS9duR3VoFORlCCW2927b0DlgcU90BIr41/jAZfy4Q== X-Received: by 2002:a05:6830:1550:b0:6b8:97b8:399f with SMTP id l16-20020a056830155000b006b897b8399fmr10450647otp.34.1688920217337; Sun, 09 Jul 2023 09:30:17 -0700 (PDT) Received: from [192.168.0.12] (host197.190-225-105.telecom.net.ar. [190.225.105.197]) by smtp.gmail.com with ESMTPSA id e16-20020a0568301e5000b006b962881479sm212147otj.20.2023.07.09.09.30.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 Jul 2023 09:30:17 -0700 (PDT) Message-ID: <1e686508-3244-178e-d837-49f7eb952e4c@gmail.com> Date: Sun, 9 Jul 2023 13:30:17 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20230707102136.16235-1-anton@khirnov.net> <6659e86-e959-9c42-ba13-8e1da890c46@passwd.hu> <168889665180.542.9354129396884912818@lain.khirnov.net> <67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu> From: James Almer In-Reply-To: <67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu> 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 7/9/2023 1:23 PM, Marton Balint wrote: > > > 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. If we make the urandom/getrandom() path block and potentially take 1-2 minutes, then I'd prefer if it's last in the function, after all available external implementations (Some of which can fail) were tried first. _______________________________________________ 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".