#1419 Issue closed: Upgrade ReaR GitHub Security

Labels: enhancement, fixed / solved / done

schlomo opened issue at 2017-07-17 08:18:

I would like to improve the security of our ReaR organization at GitHub:

My goal is to ensure that we - as an Open Source project - did everything reasonable in our powers to ensure that ReaR only contains our code and cannot be used to inject hostile code. As our code must run as root and not as user I feel that we owe this to our users.

If you see other measures to take please add them here.

ATM not all of @rear/contributors have 2FA enabled, so that I cannot enforce it yet.

jsmeix commented at 2017-07-18 14:52:

@schlomo
in general I agree (but I did not yet check the details).
I think we should try to get it done for the ReaR v 2.3 date
which is currently end of October 2017.

gdha commented at 2017-11-27 16:43:

@schlomo I will sign my commits in the future with my GnuPG GitHub key.

jsmeix commented at 2017-12-01 13:38:

Nothing that needs to be finished for ReaR 2.3
so that I change the milestone to ReaR 2.4.

gdha commented at 2018-05-10 08:40:

@schlomo how far are we in the process? Are there any developers not yet compliant? If so, a deadline should be provided before they are kicked off. What do you think?

jsmeix commented at 2018-05-25 09:34:

As far as I understand
https://help.github.com/articles/about-two-factor-authentication/

In GitHub's case, this additional information is an authentication code
that's generated by an application on your smartphone
or sent as a text message (SMS)

it seems it means I must tell GitHub my private mobile phone number
(I neither have a smartphone nor a company phone).
If this is true I am wondering about how this is in compliance
with the basic ideas behind the General Data Protection Regulation.

schlomo commented at 2018-05-25 13:33:

@jsmeix have you tried setting it up? My 2FA page looks like this:
github 2fa example
As you can see the phone is only a fallback solution and you can easily use a U2F key instead. The general advice is to have multiple 2FA tokens in case you loose one. If you don't have hardware to store your OATH token then you can use a soft client

jsmeix commented at 2018-06-05 08:18:

I have now set up 2FA.

gdha commented at 2018-06-13 05:58:

@schlomo I guess we have everybody on-board? Can we close this?

didacog commented at 2018-06-13 10:03:

Hi all,
I've just seen this. This is required by all contributors or only those who have RW access to ReaR repo?

schlomo commented at 2018-06-13 15:09:

No, this is only for write access to our repos. You can read without 2FA on your GitHub account.

schlomo commented at 2018-06-13 15:12:

Thanks to everybody for enabling 2FA, I activated the enforcement on our GitHub Organisation:
image

schlomo commented at 2018-06-13 18:11:

I have also enforced signed commits on master:
image

jsmeix commented at 2018-07-02 08:40:

Only FYI:

It seems the Gentoo GitHub repository has been hacked, see
https://www.reddit.com/r/Gentoo/comments/8une10/has_gentoo_github_repository_been_hacked/
which reads (excerpts):

This guy appears to be the attacker:
https://github.com/gentoogang
He registered 5 hours ago. He somehow got administrative access and
then removed everyone from the Gentoo organization.
He also messed with the repositories/mirrors there. :/
...
He did hack an admin account. We know which admin account was hacked.
...
Did the admin account have 2fa?
...
It did not.
This particular admin was not an active GitHub user and failed to enable it on github.
His passwords for other sites leaked and there was a pattern in them that
made it guessable from the leaked passwords.
Going forward, all Gentoo github organization members will be required
to enable TFA.

schlomo commented at 2018-07-06 12:07:

@rear/contributors I disabled the requirement to sign all commits in master branch in order to unblock our development and merging PRs from other developers who don't sign commits. I hope this agrees with all of you, we can come back to this later.

jsmeix commented at 2018-07-06 12:57:

@schlomo
thank you for that!

I appreciate it very much that until we found a way that works well in practice
we prefer to be friendly to external contributors over too hard security requirements.

Perhaps in some time signed commits become a de-facto standard on GitHub
so that we can then "just require" them (I notice here and there people
who demand signed commits plus 2FA should be used by default on GitHub).

FYI:
I would not mind if I need to do some extra steps to merge an unsigned
external contributor's pull request but I want to keep the git history.
In particular I do want to keep the external contributor
as the original author in the git history so that e.g.

git log --format="%ae %H %ad%n%s :%n%b%n" --graph | fmt -w 120 -u -t

and my personal favourite

git log -p --follow usr/share/rear/path/to/some/script.sh

show correctly who was the actual author of what code.
I need that for example to be able to ask the actual author
when I do not understand what a particular code does.

schlomo commented at 2018-07-06 17:05:

Yes, I agree with you @jsmeix. Some day somebody will have time to play around with this and describe a working mode that is suitable for us all.

[Export of Github issue for rear/rear.]