svn commit: r274739 - head/sys/mips/conf

[Ian Lepore]

On Fri, 2014-11-21 at 13:57 -0800, Adrian Chadd wrote:
> On 21 November 2014 11:53, Mark R V Murray <mark at grondar.org> wrote:
> >
> >> On 21 Nov 2014, at 19:41, Ian Lepore <ian at FreeBSD.org> wrote:
> >> The arrogance in the way you talk down to me about my right and ability
> >> to decide these things is mind-boggling.  It's clear you're going to do
> >> whatever you want, so I guess I'll just shut up.
> >
> > I’m sorry for offence; that was unintended.
> >
> > Was *was* intended was to attempt to engage you in dialogue. You are
> > obviously annoyed, but after rather a lot of discussion (2 devsummits,
> > 1 EuroBSDCon and a lot of email), some form of consensus was required.
> > Unfortunately you are not one of those who could not be accommodated to
> > the extent that you desired. We obviously couldn’t make everyone happy.
> > Some aspects of the compromise were things *I* really didn’t like.
> >
> > I think there are ways round your problem, and I’ll be happy to help you
> > get there. Please don’t just hold out for one particular solution; be
> > flexible.
> 
> Unfortunately there are things that the real world expects on these
> silly embedded platforms that we can't avoid:
> 
> * sshd as a requirement for remote access;
> * HTTPS as a requirement for remote access;
> * crypto available for WPA/WPA2 key negotiation for wifi access;
> 
> and so on.
> 
> So, we can't just "not" have random ready early at boot and only use
> non-crypto services, because the real world knocked on our door and
> said "We don't care about full security at boot; we'll gather entropy
> and improve things soon."
> 
> So yes, I +1 needing some build option that lets us feed some crappy
> random numbers out at startup. I dislike it, but the realities of
> these ubiquitous embedded platforms is unfortunate :(
> 

Just for the record, what you're describing and asking for is really
unrelated to what I've been saying.  It sounds to me like you're saying
you want a general purpose device which WILL be exposed to all the
hazards of the great wide world to be allowed to operate unsecurely in
the face of those hazards.  Maybe there's validity in that, maybe not.

My situation is different... I'm talking about devices in which there is
no exposure to such hazards, most often because the device is a small
part of some larger system and the protections are provided by the wider
environment (if that's even an issue, for example if a network
connection is even part of the system).

But in the wider sense, I've also been talking about policy, and who
should be in control of it.  Traditionally it has been in the hands of
system administrators.  Newthink is apparently that they're too dumb to
get it right and policy should be dictated by software authors.

-- Ian