Hi all, I'd like to separate two things here:
a) basic good practices with repo security by asking for 2FA for all committers, and b) changing our build/release process with high security in mind. On Wed, Aug 10, 2016 at 4:40 PM, Matthias Bussonnier < [email protected]> wrote: > Should we start a process enforce for everyone ? We can also turn on > Protected branches, that force master to be modified only through PRs, > which is less strict, but can still block some workflows. > This is about (a), and I would like to start by *very strongly encouraging* everyone who has commit rights to do this. For reference, this is the incident Thomas referred to http://www.kennethreitz.org/essays/on-cybersecurity-and-being-targeted It is recommended that you use something other than SMS for two-factor but you can use that if that is the only viable option. There are instructions here: https://github.com/blog/1614-two-factor-authentication You should also make sure that you retrieve and save the backup recovery codes, in case you find yourself needing to access your account without your mobile device on you, out of batteries, etc. If anyone is curious, not using SMS is the official guidance provided by NIST, which is the agency that deals with crypto standards for the US government and public: https://pages.nist.gov/800-63-3/sp800-63b.html specifically, section 5.1.3.2. Out of Band Verifiers states: Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. [...] . OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance. We can then revisit this later and see if it's worth tightening further and requiring 2FA. I've been considering signing my git commits as well as the releases > with a PGP key. I need to re-create one. I haven't investigated how to > automatically > verify these though. And if there are common practices on the Python > world to deal with that. > This is really (b). Good security practices in the complete build/release/distribution chain is a very complex topic that none of the core devs are experts in. Rather than trying things here and there, I think that if we're going to do something, it should be because someone volunteers to take the lead on really learning what the best accepted process is today, and then providing a clear set of guidelines for us to follow, vetted by others. Until then, it feels like just turning knobs at random without a clear understanding of where the actual weak links in the chain are. So on (b), I'd hold off for now on engaging any serious effort and keep on monitoring what other projects do. Now, if anyone is going to volunteer to draft such a guide that would meaningfully improve things for us and that is solid/vetted enough to be accepted by other similar projects, great! But until then, I don't see the value in burning our scarce cycles here. Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail -- You received this message because you are subscribed to the Google Groups "Project Jupyter" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAHAreOrNLT_6ahmm7SeKsVwBnF8vKcjD4GzChS8hJw8L7Gts7Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
