> On Sep 14, 2022, at 8:55 PM, heiphohmia via Metamath
> <[email protected]> wrote:
> It mostly boils down to an experiential difference---"live" updated page vs
> "static" site with periodic updates. I'm clearly biased to thinking the former
> is way cooler.
That doesn't seem important to me. After all,
we don't create new theorems THAT quickly :-).
Rsync is *remarkably* efficient in the "no change" case. Mirrors could poll
hourly
(or even more often) with no problem.
>> We really *can't* handle such errors. If the other side is inaccessible, or
>> can't write an update, there's little we can do about it.
>
> SMTP might like to have a word about that :D
> Transient network errors have to be handled or ignored by *someone*, be that
> us.metamath.org or the mirrors.
Sure, but the mirror admin will have to fix the problem. If there's a network
problem
that doesn't affect us.metamath.org but DOES affect the mirror, the mirror will
be in a
better position to do something about it. A more likely problem is
out-of-storage at the mirror site;
again, we can't solve that, only the mirror can.
> Anyway, security-wise, the pull model implicitly delegates trust out to each
> of
> the mirrors. If any of them are compromised, then up to any (not unheard of)
> rrsync bug, us.metamath.org is hosed.
No, we have other lines of defenses even in that case:
(1) The login shell is still disabled, making "use login shell" tricks not work
(2) Even if rrsync sandbox is escaped and the account is fully taken over,
the attacker only gets a separate user account created for that mirror with no
special privileges. It's *not* a privileged account. The mirror account
can't modify the files being served by the webserver (owned by user
"generator"),
and it can't see private keys (owned by user "root").
The attacker would have to use yet another vulnerability (e.g., a kernel
exploit) to get real privileges.
To make that harder, I've hardened the system & the system auto-installs
security updates.
That's on top of the other defenses to *get* to that point:
a) The mirror system has to be taken over and/or have its private key
exfiltrated
b) ssh and/or rrsync are subverted. But both are relatively small, widely used,
and
specifically intended to be securely usable for these purposes.
Sure, an attacker *might* get through all that. Worse comes to worse, we trash
the
virtual machine, create another, and re-run the script to recreate the site.
> Anyway, modulo other constraints, in my "make everything stateless containers"
> world, the default tends to be to avoid polling as much as possible, so adjust
> priors accordingly.
I don't have any allergy to polling, and a web server necessarily has state
(that's what we're serving!).
I think the key is that we can always revisit this stuff later.
My goal is to "make it work reasonably well" for now, so that everything is
automated.
--- David A. Wheeler
--
You received this message because you are subscribed to the Google Groups
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/metamath/F2ED7D9C-0D8B-49E5-9138-0936C446B866%40dwheeler.com.
