Re: where to set/override entropy $random_file location?

[Greg Troxel <gdt%lexort.com@localhost>]

Steve Rikli <sr%genyosha.net@localhost> writes:

>> Agreed, except I think it should just call /etc/rc.d/random_seed.
>
> Ah, I hadn't considered that. After briefly looking at FreeBSD's cron
> for regular entropy regeneration, I wondered if perhaps that duty needs
> to be part of NetBSD /etc/security script at all. I suppose it's a
> convenient place for it, since it's already part of the daily cron.

I would put it in daily, but that's bikeshed coloring, and I lean to
changing only what's wrong.  Yes, random bits are security relevant, but
/etc/security is about looking for trouble.

> I was thinking I'd give it another day or so and then put in a PR, at
> least as a placeholder to capture and summarize this thread. Is that
> worthwhile?

Yes, but the more you can have patches the more likely it is someone
will deal with it.

> While I've submitted a few PR's in the past, I've never contributed
> code, diffs, patches, etc. to NetBSD. Frankly it's even been a while
> since I used build.sh or pkgsrc -- I've been almost entirely using
> binary updates since I returned to running a few NetBSD systems.

build.sh is really not hard.    See sysutils/etcmanage and BUILD-NetBSD
for an opinionated HOWTO, but really the docs are ok.

> In short, I'm not a developer. But for areas like this, which are more
> like systems config and scripts than kernels and libs and such, I might
> be able to help a little.

We always try to armtwist into more help :-)

This is all shell script and sysadmin, really -- there's no C, no
locking/threading/interrupts.

> Is there a getting started primer in the wiki or the Guide? I searched a
> bit but not thoroughly; so e.g. I don't really know where to start for
> something like "generate diffs and make a patch for these config files
> and man pages, and here's how/where to submit them".

I am not sure.  But basically

  - check out netbsd-current

  - use build.sh (via my script, someone else's, or just create a 1-line
    /bin/sh), all the way to 'release'

  - install in a VM

  - figure out your etc strategy when updating, choose one
    + full manual
    + etcmanage
    + sysupgrade
    + something else I don't know about

  - in src/etc mostly find security, defaults.  Figure out what ought to
    change, trying to be minimal while fixing the mess.  Change it.
    Drop a COMMIT_MSG in src/ that explains the changes.

  - run a release build again (with update, if you want)

  - update the VM using the release sets.  Of course the real changes
    are in etc and hence my comments about your etc update  strategy,
    but with a test vm you don't configure much unpacking etc.tgz and
    diff/manual is not that hard.

  - cvs diff in src, and send that and the commit message in the PR


This way you can test your changes, as while this isn't super hard it is
very likely that anyone would get it not 100% right the first time.