[sf-lug] gpg, dd, find, tar, cpio, bugs, pax, ... oh my! :-)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> To: sf-lug <sf-lug at linuxmafia.com>
> Subject: Re: [sf-lug] Thanks!: Re:  ... list_members -f sf-lug | ...
> Date: Mon, 2 Feb 2015 16:55:49 -0800
>
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> On somewhat similar note, find(1) and dd(1) are rather gross aberrations
>> in Unix, etc., regarding "standard" syntax.
>
> I've gotten lost in GNU find's man page for days, and been grateful I
> brought along a crust of bread.

Yup, ... pretty annoying.  Not only does GNU find(1) add a whole lot of
stuff that is highly unnecessary (or worse), but the man page is also
cluttered with a bunch of common sense stuff that ought be well known or
easily inferred by anyone reasonably competent in Unix/Linix, e.g. like
going on about race conditions (duh, the [l]stat(2) is not synchronous
with the execve(2), there is inherent race condition), or don't do
stupid stuff with PATH, and especially not in stupid places to do so.
Why don't we go ahead and add that to every man page where it applies,
we can bloat the man pages by at least another several hundred to
thousand pages or more ... sheesh.  Folks need to apply common sense and
logic and use it ... not redundantly spell out that same information
across hundreds, if not thousands or more, of man pages.

With (GNU) find(1) I *mostly* stick to the POSIX/SUS stuff - whole lot
less stuff to even have to think about or remember, and most of what GNU
adds atop that is of negligible value, or less.  There are, however, a
*few* dang useful (and one even important) bit that GNU adds to find.
First of all, there's -print0 - not only highly useful, but *important*
(BSD also often similarly adds -print0 or -0 options to many relevant
commands), as newline is valid character in a filename (which anyone
competent in Unix/Linux ought know, and GNU ought not have to spell
that out on their find(1) man page).  The other bits that GNU adds
which I find quite convenient: -mmin, -cmin, and similarly but to
lesser extent, -amin.  -newer (with suitable mtime set on a file, e.g.
via touch(1)), can be a very good but less convenient substitute for
-mmin, but POSIX/SUS find(1) has nothing that well substitutes for
-amin or -cmin.  Years ago, I wrote a filter program - named cnewer -
that I'd use for filling in that gap - would pass through pathnames
with ctimes newer than the mtime of a reference pathname.  All the
other stuff GNU adds to find(1), I'm sure I could do without (and
really, can't think of any single additional GNU specific option to
find(1) that I've ever used, or ever needed, as I peruse GNU's man page
for find(1)).
$ lynx -dump \
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html |
> wc -c
35899
$ man find | col -b | expand | wc -c
73613
GNU find(1) approximately more than twice the size of POSIX/SUS.  Sounds
like (mostly) GNU bloat to me.

> The big functional difference between it and dd, in the 'man page sucks'
> area, is that basic functionality of dd is so well known and obvious
> that you scarce need the man page.   Trying to go without the GNU find
> man page is more of a challenge.

Well, for GNU find(1), I quite well know the POSIX/SUS find stuff,
and mostly ignore the GNU bits, other than those few specific extensions
I mention that I actually at least sometimes use.  With the frequency
with which I use find(1), that's enough to mostly keep around in my head
... but don't want to waste the valuable wetware storage space with all
those other GNU extensions.  (nor certain aforementioned [OT] cr*p I was
"forced" to read back in high school).

For another example of GNU bloat (and bugs!), have a read through this
earlier posting of mine:
[buug] Why I tend to prefer pax(1) over tar(1) and cpio(1) ...
http://buug.org/pipermail/buug/2012-October/003944.html

> [root keyring:]
>> Not necessarily.  And much like the mail command shown earlier in
>> pipeline, that need not be run as root.
>
> Clearly (and doing it in /etc/crontab is more straightforward than with
> 'su'), but that introduces an extra layer of baroqueness that I'd rather
> do without.  Also, I class this as a system cron job; system jobs should
> IMO not rely on non-system users.  (I could create a system non-root
> user, but, again, baroqueness.)
>
> Nothing we're doing in the job is the least bit dangerous, so running it
> with root authority doesn't bother me in the least.

Yup, ... convenience/simplicity/etc. vs. security ... and as you well
point out in this case, adding the complexity would give approximately
negligible security gain - so probably very much not worth adding the
complexity in this particular case.

>> Yes, shared secret - low tech start, but can also be usefully utilized
>> to effectively bootstrap other authentication/security (e.g. when one of
>> two users hasn't already generated their PGP key for keysigning event,
>> or the highly common case, a user's initial temporary password).
>
> Are you sure you can't validate my key
> (http://linuxmafia.com/~rick/rick-moen-publickey.gpg) through a
> reasonable-sized chain of signatures?  At one point, it was highly
> connected via Drew Streib and Ted T'so's keys, among others frequently
> in other people's webs of trust.

I probably can, but I was thinking more the other way around - how would
you have trust path to newly created sf-lug key ... and (pre-)shared
secret was probably "good enough" to manage to bridge that gap.

>> Thanks, and yes, tested, looks perfectly fine!  :-)
>> I was able to snag the file via http and decrypt it without problem.
>
> You _could_ add it to your rsync job, if you prefer.  As you know.

Yes, but for *encrypted* content, no real advantage to using rsync,
hence I was generally thinking to go with the simpler http, and leave
rsync out of the (encrypted) roster "solution".  However, on the
receiving end, after decryption, RCS can well be used to efficiently
effectively store various versions and do some reasonable tracking of
changes (at least what and when relative to versions retrieved, though
automated means won't spell out the details of the "why" - beyond that
it changed).