| 1 |
On Wed, Jul 3, 2019 at 12:31 AM desultory <desultory@g.o> wrote: |
| 2 |
> |
| 3 |
> You based your argument on your preference, as opposed to reality. |
| 4 |
|
| 5 |
This entire thread is about preference. The reality is that you need |
| 6 |
to use your real name to contribute to Gentoo right now. You would |
| 7 |
prefer that it be otherwise. There is no harm in expressing that. |
| 8 |
|
| 9 |
> Accepting and providing payments are fairly basic operations |
| 10 |
> for legal entities to engage in, even if the foundation were to be |
| 11 |
> dissolved there would still be financial transactions apropos Gentoo. |
| 12 |
|
| 13 |
If we were operating under an umbrella org, Gentoo would not be |
| 14 |
legally responsible for these activities. |
| 15 |
|
| 16 |
Also, I believe that these activities should STILL be minimized, |
| 17 |
ideally towards zero. Physical servers and bank accounts are |
| 18 |
vulnerabilities that can be disrupted. The less you depend on them, |
| 19 |
the more resilient you are. |
| 20 |
|
| 21 |
If Gentoo were nothing more than a git repo it would be almost |
| 22 |
impossible to disrupt its operations as these are trivially |
| 23 |
replicated. If the services it did run were entirely open they would |
| 24 |
be trivially mirrored (I mean open everything - not just the upstream |
| 25 |
code, but all our configs/etc - obviously short of the credentials). |
| 26 |
|
| 27 |
Yes, I'm obviously speaking aspirationally, but the principle is still |
| 28 |
valid. IMO FOSS solutions for replacing some of the infra-heavy |
| 29 |
existing solutions like bugzilla are lacking, so this could be a long |
| 30 |
road. However, anytime we deploy something new we should be asking |
| 31 |
whether any Gentoo user can trivially replicate the entire service |
| 32 |
based on our documentation and published data (ideally with a few |
| 33 |
lines), ideally including even authentication (no reason a Gentoo |
| 34 |
credential shouldn't work on a non-Gentoo site in a world where |
| 35 |
federation is common). If the answer is no, then we're creating a |
| 36 |
dependency on some black box that could be taken away from us. |
| 37 |
|
| 38 |
> In that case, you are advocating for having no: passwords, password |
| 39 |
> hashes, private e-mail (including security related correspondence), no |
| 40 |
> encryption keys, no signing keys, no pre-release code, no closed source |
| 41 |
> code, no code not meant for release for any reason at all, no |
| 42 |
> confidential data at all, and probably other things that I neglected to |
| 43 |
> list. |
| 44 |
|
| 45 |
None of those are really PII. However, we should certainly be |
| 46 |
minimizing our dependence on all of these. We should depend on actual |
| 47 |
PII even less, and I'm skeptical that we need to retain this at all if |
| 48 |
we stop operating a legal entity. |
| 49 |
|
| 50 |
I'm not saying that we'll ever reach zero, but anytime we can |
| 51 |
accomplish our goals without resorting to using the laundry list of |
| 52 |
stuff you just provided, we should. |
| 53 |
|
| 54 |
-- |
| 55 |
Rich |
Archives