Definitely the latter, and I'll leave it to @fluxo to coordinate with you on security.
For the former, we could probably arrange some shared groups and whatnot. I don't recall our specific plan with LP and ability to construct various groups. And given that we might switch providers, I'm not keen on spending time to figure it out, beyond a simple archival of your key and passphrase. Longer term, we could look at more direct support for our PMCs. Not sure what form that would take, as you're the first to ask for such. (note: likely not cuz you're the first to need it, but that you're the first with a security mindset) Does that work for y'all? On Mon, May 15, 2017 at 5:49 PM, Kevin A. McGrail <[email protected] > wrote: > Is lp available for projects? > > And/Or do you envision we create a key for say [email protected] and give > you the private key and also a passphrase out if band. Then we add > [email protected] to any thing we encrypt as a recipient and that is a > safety valve? > Regards, > KAM > > > On May 15, 2017 6:35:56 PM EDT, Greg Stein <[email protected]> wrote: >> >> We currently keep many credentials in LastPass (*). ... If y'all would >> like to construct a recovery key for SA, then we'll happily store that into >> the ASF LastPass account. >> >> Cheers, >> -g >> >> (*) after a couple LP security notices, we are considering other options, >> but that's neither here/there. if we switch vault providers in six >> months... we'll *still* have one for an SA recovery key. >> >> >> On Mon, May 15, 2017 at 5:27 PM, Kevin A. McGrail < >> [email protected]> wrote: >> >>> Greg, >>> >>> Dave Jones brings up a good point about longevity of encrypted things >>> for the foundation. Could infra maintain a key that can be added to things >>> for a backdoor? >>> >>> See below for a snapshot of the relevant thread for background. >>> >>> Regards, >>> KAM >>> >>> KAM: >>> What you should do is use the pub key at http://people.apache.org/~kmcg >>> rail/ and encrypt a file with the password. <soapbox>Ideally, you >>> already have a key for me that chains to a circle of trust so you know for >>> sure it's me. They actually have key signing parties and stuff for this. >>> I've found it to be a PITA and doesn't make me feel better that the key is >>> valid. It's not like we are trained in verifying fake IDs so it's nothing >>> but an illusion of trust.</soapbox> >>> >>> Dave: My concern is I can sign it with your (Kevin's) key and even >>> Brian's key so the two of you can open it but what happens if another 5 or >>> 10 years go by and we 3 are no longer volunteering as SA sysadmins? The >>> next generation of sysadmins won't be able to open these files. >>> >>> There has to be a better way where we use an encrypted file with a >>> master password that we share and is recorded in a save place for the >>> future. >>> >>> I use LastPass for this and I have my master password in an envelope in >>> a safe for my wife to open in the event I am no longer on this planet. I >>> have instructed her to take this envelope to any of my techie friends and >>> they would know how to help her get access of all of my online accounts. >>> We need something like this for this team. >>> >>> KAM: The first consideration is that the method above with SVN is >>> considered acceptable to the foundation and exists already. It long >>> predates me and has a strong encryption pedigree. It also doesn't rely on >>> a service being in business since it uses all open source software and >>> files that you can mirror today. >>> >>> What I have done that is similar to what you describe is that my >>> passphrase for my private key is in my safe. So should I leave this mortal >>> coil, the data is all recoverable. >>> >>> Also, we are trying to move away from master passwords as much as >>> possible. Sharing of root credentials should be avoided as just a general >>> security mantra. >>> >>> KAM: Do you feel strongly enough about it to debate it with infra and >>> see what their thoughts are? >>> >>> Dave: Not that strongly. I will be glad to go along with the existing >>> standards. Seems like there should be an escrow-ed key from the foundation >>> or something that we would also sign with for the future. >>> >>> >>
