[sf-lug] ... list_members -f sf-lug | ...

[Michael Paoli]

Rick,

Here's basic idea, if it's okay with you - at your earliest convenience.
And shouldn't be too hard to implement on your server side.  In addition
to emailing me sf-lug roster weekly (can later drop that bit to me after
I've fully verified ...) (and Jim Stockford - probably no reason to drop
sending to him), wee bit of extra crontab for you to run, preferably
daily (but weekly is also quite good enough) - but instead of
emailing it, pipe the roster through:
gpg --armor --yes --batch --trust-model always --encrypt --recipient \
0x960C4BE648737D4287DC188FE8A55E60878BD8C0
(might also need to first set umask or file permissions)
And then redirect stdout from that to world readable file
(suggested name: sf-lug_roster.asc)
somewhere accessible via http.
And let us know the URL to snag that file, and I'll set up process
to then regularly copy that to the sflug host (which is also, itself,
in turn, backed up rather regularly).  Those with root on the sflug host
have access to the corresponding secret key (I also have off-site copy).
You'll also need that public key - I've not uploaded it to keyserver(s)
(don't presently see need/reason to).  I've signed the key, but alas, I
don't see that you've signed any of my keys.  So ... for some
reasonable degree of assurance that this is desired key, and not
something that's been man-in-the-middle (MITM) attacked ... (pre-)shared
secret.  I'm guessing/hoping you still have the temporary password we'd
earlier set up when we had the "recovery" environment (booted from added
ATA hard drive) temporarily on your host - if I recall correctly, I
believe you also recorded said password on convenient non-volatile media
(pen on paper).  If you've got that, you can use gpg to decrypt the bit
that's encrypted further below - it's simple symmetric encryption using
that same password as passphrase for the encryption.  Once you decrypt
that, you'll find it contains the public key, and with fingerprint also
matching the below (unless MITM mucks with bits not encrypted ;-)).
In any case, that password, used as passphrase, should get you the
public key and correct fingerprint (and be tamper-resistant means,
presuming that password still happens to be secure).  If you no longer
have that password - or it's no longer secure, we can verify fingerprint
via other out-of-band means (e.g. phone call) and I could simply email
you the public key.

Oh, also, no guarantees the email address on the key is mailable (per
standards, if the domain is, it would be ... but at present the domain
isn't ... and don't know that that will be changing anytime particularly
soon).

Below, the relevant data bits, and following that, bit 'o rationale
and some references/excerpts and other comments and miscellaneous bits.

$ gpg --with-fingerprint --list-keys \
> 0x960C4BE648737D4287DC188FE8A55E60878BD8C0
pub   4096R/878BD8C0 2015-02-02
       Key fingerprint = 960C 4BE6 4873 7D42 87DC  188F E8A5 5E60 878B D8C0
uid                  San Francisco Linux Users' Group (SF-LUG)  
<postmaster at sf-lug.org>
sub   4096R/2830B82F 2015-02-02

$ gpg --armor --export \
> 0x960C4BE648737D4287DC188FE8A55E60878BD8C0 |
> gpg --armor --symmetric
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.12 (GNU/Linux)

jA0EAwMCx5xOunt4pldgyevuaNTxTIfk9YXSLBP1gQmtLJC47wfomrjZn2MfsIQc
g6JKZAbznbpYC2f+5DXI5SCveVZTjUsFzB8OOSPvZEM7dLkzn2wDcadVRMjKgulb
neFR0O4QfxeMF/IQTWbQ9YX2hAOZGuiok6iPVA3MuTCqGE/+sPxVn63nzCXL4+Mh
/oPlDE3h5o6RMjwl+EWKmCk+rK4DNTQspZyFcrGJvfV/O/LcmJPnWzhEUGqKx8OX
z5GDmjWszk64QDgdNwB5DjEnb1u4oDv2fihNuMLxQiWGA91wL8VqIzgAgUcPvZtd
+GyJu0HbJYgRKb+NoAwHzcB5mPpFmjDcLz6kN7lxjWMG39iFtExpqBUAMS0qkHhb
vk2XJY/AO/hceCGxlqpgi0T0XNEMDirhTX5rveI3nElKoE4Qd35fFHb1bnLKtHMa
duwCZ7eQlULbrgkcSF/4k/lSA4OqpVWQOQwdIIDktM39thVe3KlA3saFu55mtt9W
WCB3Pi4FahAPVam/WvWcUNMp4BawaTz1jqfScphHxO/8/jaMdjNK8aJhHgtCYdAE
ViTPDWc0V31mpqzev9xXWoXSfjhxHnr/kTVkO1fwHoX9E7olXU23bNedOy2Lmp+a
UMzau2RkReXZ4Hjy346hBM+ex5f1ugEJqWgQyP8lEsR+2IQZQvBo9Frzjb1rxQlH
ZVr7hoYcyaV+hBbQZOCe1EhC/ESrHgz6blSzY8D6cwNMR2H3XyfNiUQUxWU4dsiQ
mnvV1T6PGxOtE6mwxf5VERTLKCksUxQM/Q3vwtWf8KwIkEmZ884/BsiO3/C/2QCd
w1+Y/rVmmTosTRp4zK93/ngL4OR8TPdq43VXtWPs86/y0m5E0TGjSUZzqLzZQobT
Fk8FOjhwuYLs/cHyHVDFsklcfBKWGrGixmDUQRtA0Zm59fQvfSUv3uDlKISbnam5
HnJr+AY5svqQMaKLAdG9T+NDckf8tP5j29kNHbEY9jdstV39AWn3SkO4I+5MvnS0
P1OKt3BI8+gyRyuWsDfD1X1z4lidlMzmxHHttMBzqwEySFpnChWfum2FrkPXHfig
2MCRSa4ACSGc5/tbLTQxGE6IFs4uCq+iJbM9swTmUsP7yomaruRVXfOX8ZxzTX3R
MEK0hl+9/Mn/KMjce3vNh7ip309Zx90OSOw2K00F6YCZBWQcAkRHu/AYtzgu7/50
AECduFSALQNAKWFi+VcZXo6TxroTqezLx1bfvb/49OR1EKTjdI2IADp+uQZlb2m8
UY8S1P4hGYhhJwpRZhbwURnP2fB2rINZL4iFg7K9JjOpdB+eneW2IHiuV3xCQ8+A
B1XWN9uP8kcvE56auYXSrXPn/Bv/+40zTg1ayuZaYF/tu0j7VlnxAllCiQ3RLrLM
QmVuJm+J8W0ASSYgXhUemAYkU1ZQQrq+f8XMstE8oBikB1zOxDDh1ZB9D/tCd9Ps
2cVDgXZ2R/7B+0/0i01qNVTh5vDZgrpKU6YsTsl34FQQoB/RVKlj0nkJundViPfM
lrUOrM+A0BAaXzpfSB/su2/Qb9AFXZOaQFKTihIj7E8FGT+8d8KCNo3YbzAYkxaq
G3DTAmS0osbjHsdq8BhLV9EPAMzVg+gEmL/8KRQAwrRgIp0dO2d5VKJuZO4fxinl
D830byLaGIANNk/0T4cjQZK7WeWLS1cxyc38LBBLguOw9d+eOGAIdO4lw/N9oE8U
i6mIX7GmHKm5JYqoOMonJ5DodwUsYr3nOc4v0K7/ybb1YrHA5H2IhuFtL6rBjMLN
N9/ocU5m1UyciYXtTlE61Me6qqrBHXOrg67CXfmlK9gCDrZH0eviwdssWr9Pqeym
ueJ5e0mGosdqmJ+FtdxO/vSW4B5CNZF9/GguSftUel5zfPOWZjSyfIcoB4HPzZmj
OKpr4O8mtUrOZR+Gz45Mg4aOjFftZETiL3LzKBRBxdQnRr7h8RCzQFujpkXx9Sye
tKIuBplF2vHxQUbZan+oGBz2qD3yIy+kjSzgVz45HgO9kvK2QUKDtqpLamwp60RS
vX0zeZxAdrUSoscXmNFPwRygaGyv4KJMnjFL9kkHjnq5G+Y9nZ/AgYcjYLRyx4ej
jTTJKg5R7Ulo/gRxLrLwnQaUvGQ/RE2FNPV4Wtz1u04RJBdkZbdDoqECzZjfLMNZ
Li2z8RzBBsi+kkweAvTV5EO1/hiF+cV/hGfTZsBiusJqKNsFIxFbtu22R2bChDDS
eY+SnSbu7+KXUVDtGNhQdla3cV3Uw7qyxIlHPMfBj5gynH1eVhXsVsb5GsoIeV0/
xFoLOfM6TF464t2acM7o+KmP2P0xauYxdmEV9tt7PQyDwi4/1EN6JdSb13BozSu/
cNADPMcrXPoXU+icLA1B3K6VMm718hkOhrU7smBZ92WMegSYz80zw+qYvE9TGC+f
LP5MFUKpOC2PnKa90+05ReIPLOdta0hGJdCFGCe3eVF2dY7QxIKTSt6Q7OXbMF8R
7qFeTNRcp8yfsTlUDUdSRB7XETJJfQxYO3mh5WryPbwrsPQNnTuklwKZ55Qd/z5n
3zO/GIrFGj/aE4VmmjJLr0H4fSf6lxgqNLIzuoHz9gvLHonxvKw1suP0azRyQpRb
kvsCkIQQn7QXVSoxQ7/BfPO7D8XJuTWmynpLvTz+FCkGmD8dwLB9xD9hZVaSqhfX
shyK2DUCdBhnlfKO0F/FRBPGWb2m/biyOhwLdOirnowvnt4IkOAFptjXDWSuzXoj
UupbMDbDdmAEQ60PJ1KcY7o3vljGxhLj+7Lg2KohoQs3X7b0TVEWPtZ6QholLAhq
IoS14cK0RUE04fe/H1M0l0sEhKG4jqMzjCU7h19tsxhPsNQrIb6OjaHrtx6uQgod
ZTLgZNMeVTIFR1+DmQ+60gQN23lYvfxWiroy9x9u8NvXhflgEqGVOQMO3Ww9pqpv
XfHJhQyk25954MWdBKHEJZkccTZcUUCsIuvvmirZhpTGG8FlwiArl97HhLld95mR
xMtQ1EMfm1Vu6j8N6Tb5EgzocaX1TVwpdixFOYnb+oJnO/d5G+Jt/DoM/8hg4/x5
MMtzOLbDUmwaZiZoxzFJT7HEAcLO4WYkhWeSxH0RDO/P7XiswZbCTcrppid4ym2Z
KY2LIkIrA/VKdKVcUtKe9rzwOT/1iptv8x//zs8VT7feon90Ianf9oTotyeLURR4
SHdbHLUfUJGOhAIPiRZes+BC32hpPex+MwHuYLt2eRs8+tNE37mDhKuYlrs8hgwS
d3w0TUbnoep+mXZOLtCdNDWbz9wI4NwsZq3oqva9hXmXLZI5EJToClwxrKKpibIv
8sqyA47sZyyxRHgw1xUxvhkdU2aaXzVVwkyI8TAsGDkDbBVrzvVhqDeY3jbsRCgQ
mxgJyz2f0AjPHzGZ2iZYUMlwn+kXv6htmsWFtzmPrk3X8T4CjgXWbhszFHYlnPAU
Euh2nMy0hKE/AK9RXkKnxCOVgtz4tD6svDDUePVG/acFeKzzy6GZoAPLoQS/DZIj
Fwj7uJZsh7rFJ6TOaYjOmZhY45DHLzbpiqaBQ4WNrjy08Zw83iknYB869bDNgtui
dO1Hhh6yOXiKYAVbnjrAjfSMsbZbeedbYYVin8hSMFHEu8WyGxUsQg7wZUycF57X
vLKKr/W7i9Do6Ovz2cHmmuyZsbfYeJQcQobjKFI6uo9iYkPUxE2smqUEZ6ytR63t
gDyhy9v4yjt/ltemvYiu8r7RoUYgg+oYQos3fVryFvj17VWeKm4Is0HEAAXo5PGb
Bsu/1oCPb1pk9m9nbK1XbKW5TScePTZ6HuL/JSQk9nBamfDbMEA+wHzrzyB5tNHg
1eAnSVw86NibT/2crFYYfu8ba8csbIBmV2QLcppVaoJCIDJdGkpXEMGapqttqCvd
Hwid5cGFismckZ/48ymKsUMpebjCOSnQGV8CHBIdIvVxTrItkdS1/G9L1ksCcEbj
5sMeHlI1xW3WEcSxtpKIoWtz/yPNZH6sP+rvVlWa5Xi51MvBBqIaQ+ViifA41tU/
m8cL/T1y2UXYevVkIEWWWoRUE81+VBnHpJ5abchwLKrwoVrt5h4nYaMmRz70Jg7v
It/8jVNO36GPFuW5Bo01KaLGhMaTzx3ViwkW5HD9/4xRhL5/PBmgMYS+2cPO82si
MEierf/FiExFp3cnsYSdtoHmEMTDiK7WxPkd3mk37aQeZm8Wvy6mGsgNopHb9Bp6
B5/Ql4tA1L/0ipIFinLuwm9SNoGmUIXAQ7mew6QiOgDPu8kxg7HxCyEyFcT7RinS
CxFx8IfCsg==
=riCK
-----END PGP MESSAGE-----
$

Rationale:
o prevents general public / non-subscribers from accessing cleartext of
   roster.
o *fairly* easy to set up on server side (e.g. relative to emailing
   roster - add highly similar crontab job changing mail command to gpg
   command with stdout redirection to http accessible file location - may
   need to also set file permissions or umask)
o to be automagically picked up on receiving host side, which is itself
   backed up, and also provides generally better (or better
   supplemental/additional) access than emailing some folk(s) (though
   some of the finer points of "better" are certainly debatable)
o more simply (for certain definitions of simply) provides more access
   to relevant folks (e.g. those with root access on sf-lug host, without
   need to set up and maintain individual email addresses for same on
   originating host, nor "pester" them with regular emails of such roster
o reduces my email load by about 52 emails per year ;-), similar savings
   for others that can or do use access on receiving host (and/or its
   backups), rather than directly receiving roster in email
o can also add/drop/change downstream processing (e.g. email roster out
   or not or change recipient address(es), to various sf-lug admin
   folks), without pestering upstream source
o did also consider some ssh-based options, but they'd generally involve
   more up-stream work (in the longer term) to set up and maintain, and
   greater risk/exposure model to upstream, so "least privilege" also
   comparatively favors gpg method.  And given that roster is mostly
   (about 99% - all but some subscribers set to "private") available to
   all list subscriber, and via http, not https, the pgp encrypted is
   generally >= security of list member access to roster over
   non-encrypted Internet connections.  Likewise for emailing of roster
   (though, alas, it is an *email* list after all, so all members do get
   emailed, and that often involves unencrypted connections).
o And, it was also likely a good/useful thing for SF-LUG to have some
   kind of gpg key itself, for such utility purposes that may come up and
   be relevant - so also set up such key in the process.

I like how the encrypted bit happened to coincidentally end.  :-)

> Date: Sun, 1 Feb 2015 21:47:53 -0800
> From: Rick Moen <rick at linuxmafia.com>
> To: sf-lug <sf-lug at linuxmafia.com>
> Subject: Re: [sf-lug] {crickets} ... list_members -f sf-lug | mail ...
>       Michael.Paoli at cal.berkeley.edu ...
> Message-ID: <20150202054753.GB10984 at linuxmafia.com>
>
> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> Yes, got the (manual) roster - thanks, and have been planning to get
>> back to you on that one ... no extreme rush (I figure if it gets
>> covered once a month, that's much better than past, ... and we're not
>> yet near one month since you manually also sent me the roster).
>
> Based on that, adding you to weekly cron job, for now.  (Best to
> act and await SF-LUG deliberations.)  Mail will go out Sundays.  If
> you'd rather not get it, please expostulate.

That's fine for now - won't kill me or my email.  Thanks.

> You're requested to regard the roster as confidential.  (More below.)

Yes, already considered (much) earlier, see rationale, etc. above.

>> I've in mind something for you to implement that's just about that
>> easy (one more command in pipeline), but I need to still do more prep
>> work on the receiving end.  Then ought be able to automate the
>> receiving end ...  and have it automagically placed somewhere more
>> fitting than my email, and more regularly.
>
> OK, cool.  I was sure there was something better, but I followed my
> dictum that any half-assed solution you actually do beats better ones
> you haven't gotten around to.

Yes, quite true, however ;-) ...
... so long as that's better than lesser methods that may later blow up
in someone's face, e.g.:
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: code practices: Re: Linux Steam players should not move the  
> Steam directory
> Date: Fri, 16 Jan 2015 15:28:37 -0800
>
> Amazing what some, uh, "programmers" (or those attempting to do that)
> will fail to check.
>
> Once upon a time, production system, some more junior level system
> administrators had been taking care of the hosts - and with not (quite?)
> enough oversight.  So, one of those production applications got migrated
> to a new host - substantially different (mostly newer upgraded)
> hardware, but still same (or nearly same?) basic OS version ... but due
> to fair bit of hardware differences (notably a lot more disks and disk
> space - notably to accommodate the growing application), things
> appropriately and rather necessarily, weren't laid out exactly as they
> were before.  Anyway, one of the bits of code in a crontab driven job
> looked an awful lot like this:
> #!/bin/sh
> cd /some/log/directory/somewhere
> find * -type f -mtime +30 -exec rm -f \{\} \;
> ... oh, and of course run by root, and root's HOME directory: /
> Guess what happened the very first time that cd failed after the
> migration?  <sigh>
> Wee bit of attention to detail and as little as two extra characters in
> the code (e.g.: &&, || exit, or set -e) could've saved the day, ... but
> no, the day (and then some) was lost, when the host dutifully committed
> seppuku precisely as it had been instructed to do, and we were left to
> repair the damage, and determine cause.  And I think that crontab job
> only ran monthly ... so all seemed perfectly fine for week(s) or more,
> ... until ... yeah, not pretty.  Anyway, also best not to be remembered
> as the one who destroyed critical production with sloppy code (same
> would also have occurred pre-migration if that cd ever failed - e.g. if
> that filesystem wasn't mounted when the crontab job ran).
>
> Another case, not so ancient, I'd written some very functional working
> prototype code.  It was quite production quality, but the requester
> probably wanted to tweak the look and feel slightly, and some other
> details.  But the requester deemed my code "too complicated", and wanted
> to rip out about 2/3 of the code.  Notably most all the error checking
> and safety checking bits.  I told said requester they could do that,
> but at their own risk (and to production, as they were going to also be
> running this code against production), and all those "we don't have to
> worry about that, that won't be the case", and lots of other checks,
> they wanted to remove.  But by removing them, they pretty much ensured
> unexpected results, up to and including major disaster, would occur if
> the code was run with those checks removed, if any of those "we don't
> have to worry about that, that won't be the case" conditions (along
> with some others) ever occurred where the code was run (even as simple
> as rerunning the same code a second time, when it need only be run once
> on any given host).  I told them they could take any and/or all of
> those checks out ... at their own risk/peril ... but if they remove any
> of them, remove my name from the code.
>
> I've also, far far too frequently seen highly abominable code by 3rd
> party vendors - and yes, including for Linux.  Some of 'em even *sell*
> "product"/code that I wouldn't even barely deem to be Alpha quality -
> let alone Beta, or, egad, installed into and running in production!
>
> Some places won't let code like that get anywhere *near* production! :-)
> Others, uhm, well, managers override and ... well, sh*t happens - sooner
> or later.
>
> http://www.rawbw.com/~mp/unix/sh/#Good_Programming_Practices
>
>> From: "Rick Moen" <rick at deirdre.net>
>> Subject: Re: Linux Steam players should not move the Steam directory
>> Date: Fri, 16 Jan 2015 14:28:00 -0800
>
>> On Fri, Jan 16, 2015 at 2:04 PM, Samir Faci <samir at esamir.com> wrote:
>>> The issue is that
>>>
>>> "$STEAMROOT/"   becomes  / when it's unset.
>>
>> OK, yeah.  But in context that's just as bad.
>>
>>> What they should have done is check if the parameter is set and error out
>>> way before using the variable.
>>
>> Quite so.  An environment variable used in a recursive rm should not
>> be simply assumed to be set.
>>
>> People who do that probably can't be trusted to do other basic things
>> like input validation, bounds checking, and so on, either.

[back to earlier quoted bits]
> I could programmatically dump the roster to the anonymous-rsyncable mbox
> directory, or elsewhere.  But...  Some folks regard rosters as less
> than public, and would object to fully public access.

Yup, (relatively) confidential ... again, covered, rationale, further
above.

> /etc/rsyncd.conf's 'auth users' option seems to furnish a middle
> path, though I've never used that function.

Noteworthy possibility, I'd not though of that one.  Nevertheless, I
think (again, per referenced rationale), what I've mostly set up puts
more of the setup/maintenance burden (e.g. change of what users are
authorized to get the stuff) onto other than yourself.

[OT]
>> But, e.g., "force" me to read _The Great Gatsby_ and I can read it
>> cover to cover (and even reread the same page many times) and ...
>> interest about zilch ... retention likewise.
>
> Bleah Fitzgerald.  ;->
Egad, rather recently, and for the first time ever in my life, I saw
someone wearing a _The Great Gatsby_ F. Scott Fitzgerald t-shirt
(probably because there was the movie not yet long enough ago).
About all I could think of it was:
o Stay away from me!
o I don't want to hear *anything* of it!
o Egad, what's *wrong* with you!
and, I don't care how attractive she might have been without the
t-shirt, with it she was anything but.