[Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

[Cory Benfield]

> On 12 Jun 2016, at 14:43, Theodore Ts'o <tytso at mit.edu> wrote:
> 
> Well, it can only happen on Linux because you insist on falling back
> to /dev/urandom --- and because other OS's have the good taste not to
> use systemd and/or Python very early in the boot process.  If someone
> tried to run a python script in early FreeBSD init scripts, it would
> block just as you were seeing on Linux --- you just haven't seen that
> yet, because arguably the FreeBSD developers have better taste in
> their choice of init scripts than Red Hat and Debian.  :-)

Heh, yes, so to be clear, I said “this can only happen on Linux” because I’m talking about the world that we live in: the one where I lost this debate. =D

Certainly right now the codebase as it stands could encounter the same problems on FreeBSD. That’s a problem for Python to deal with.

> So the question is whether I should do what FreeBSD did, which will
> statisfy those people who are freaking out and whinging about how
> Linux could allow stupidly written or deployed Python scripts get
> cryptographically insecure bytes, by removing that option from Python
> developers.  Or should I remove that one line from changes in the
> random.git patch series, and allow /dev/urandom to be used even when
> it might be insecure, so as to satisfy all of the people who are
> freaking out and whinging about the fact that a stupildly written
> and/or deployed Python script might block during early boot and hang a
> system?
> 
> Note that I've tried to do what I can to make the time that
> /dev/urandom might block as small as possible, but at the end of the
> day, there is still the question of whether I should remove the choice
> re: blocking from userspace, ala FreeBSD, or not.  And either way,
> some number of people will be whinging and freaking out.  Which is why
> I completely sympathetic to how Guido might be getting a little
> exasperated over this whole thread.  :-)

I don’t know that we need to talk about removing the choice. I understand the desire to commit to backwards compatibility, of course I do. My problem with /dev/urandom is not that it *exists*, per se: all kinds of stupid stuff exists for the sake of backward compatibility.

My problem with /dev/urandom is that it’s a trap, lying in wait for someone who doesn’t know enough about the problem they’re solving to step into it. And it’s the worst kind of trap: it’s one you don’t know you’ve stepped in. Nothing about the failure mode of /dev/urandom is obvious. Worse, well-written apps that try their best to do the right thing can still step into that failure mode if they’re run in a situation that they weren’t expecting (e.g. on an embedded device without hardware RNG or early in the boot process).

So my real problem with /dev/urandom is that the man page doesn’t say, in gigantic letters, “this device has a really nasty failure mode that you cannot possibly detect by just running the code in the dangerous mode”. It’s understandable to have insecure weak stuff available to users: Python has loads of it. But where possible, the documentation marks it as such. It’d be good to have /dev/urandom’s man page say “hey, by the way, you almost certainly don’t want this: try using getrandom() instead”.

Anyway, regarding changing the behaviour of /dev/urandom: as you’ve correctly highlighted, at this point you’re damned if you do and damned if you don’t. If you don’t change, you’ll forever have people like me saying that /dev/urandom is dangerous, and that its behaviour in the unseeded/poorly-seeded state is a misfeature. I trust you’ll understand when I tell you that that opinion has nothing to do with *you* or the Linux kernel maintainership. This is all about the way software security evolves: things that used to be ok start to become not ok over time. We learn, we improve.

Of course, if you do change the behaviour, you’ll rightly have programmers stumble onto this exact problem. They’ll be unhappy too. And the worst part of all of this is that neither side of that debate is *wrong*: they just prioritise different things. Guido, Larry, and friends aren’t wrong, any more than I am: we just rate the different concerns differently. That’s fine: after all, it’s probably why Guido invented and maintains an extremely popular programming language and I haven’t and never will! I have absolutely no problem with breaking “working” code if I believe that that code is exposing users to risks they aren’t aware of (you can check my OSS record to prove it, and I’m happy to provide references).

The best advice I can give anyone in this debate, on either side, is to make decisions that you can live with. Consider the consequences, consider the promises you’ve made to users, and then do what you think is right. Guido and Larry have decided to go with backward-compatibility: fine. They’re responsible, the buck stops with them, they know that. The same is true for you, Ted, with the /dev/urandom device.

If it were me, I’d change the behaviour of /dev/urandom in a heartbeat. But then again, I’m not Ted Ts’o, and I suspect that instinct is part of why.

For my part, thanks for participating, Ted. It’s good to know you know what the problems are, even if your solution isn’t necessarily the one I’d go for. =)

Cory

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160612/bdeed302/attachment.sig>