From: James Almer <jamrial@gmail.com>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] lavu/random_seed: use getrandom() when available
Date: Sun, 9 Jul 2023 13:30:17 -0300
Message-ID: <1e686508-3244-178e-d837-49f7eb952e4c@gmail.com> (raw)
In-Reply-To: <67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu>
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".
next prev parent reply other threads:[~2023-07-09 16:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-07 10:21 Anton Khirnov
2023-07-07 11:54 ` James Almer
2023-07-09 10:06 ` Anton Khirnov
2023-07-10 12:15 ` James Almer
2023-07-07 20:02 ` Marton Balint
2023-07-09 9:57 ` Anton Khirnov
2023-07-09 16:23 ` Marton Balint
2023-07-09 16:30 ` James Almer [this message]
2023-07-09 16:37 ` Marton Balint
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1e686508-3244-178e-d837-49f7eb952e4c@gmail.com \
--to=jamrial@gmail.com \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git