From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavu/random_seed: use getrandom() when available
Date: Sun, 9 Jul 2023 18:23:29 +0200 (CEST)
Message-ID: <67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu> (raw)
In-Reply-To: <168889665180.542.9354129396884912818@lain.khirnov.net>
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".
next prev parent reply other threads:[~2023-07-09 16:26 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 [this message]
2023-07-09 16:30 ` James Almer
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=67b8bf2-7663-f5b6-6765-ccb048d769b4@passwd.hu \
--to=cus@passwd.hu \
--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