<div dir="ltr"><div dir="ltr">On Mon, Oct 24, 2022 at 4:55 AM Christoph Cullmann (<a href="http://cullmann.io" target="_blank">cullmann.io</a>) <<a href="mailto:christoph@cullmann.io" target="_blank">christoph@cullmann.io</a>> wrote:<br></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-10-23 08:32, Ben Cooksley wrote:<br>
> Hi all,<br>
> <br>
> This afternoon I updated <a href="http://invent.kde.org" rel="noreferrer" target="_blank">invent.kde.org</a> [1] to the latest version of<br>
> Gitlab, 15.5.<br>
> Release notes for this can be found at<br>
> <a href="https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/" rel="noreferrer" target="_blank">https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/</a><br>
> <br>
> There isn't much notable feature wise in this release, however there<br>
> have been some bug fixes surrounding the "Rebase without Pipeline"<br>
> functionality that was introduced in an earlier update.<br>
> <br>
> As part of securing Invent against recently detected suspicious<br>
> activity I have also enabled Mandatory 2FA, which Gitlab will ask you<br>
> to configure next time you access it. This can be done using either a<br>
> Webauthn token (such as a Yubikey) or TOTP (using the app of choice on<br>
> your phone)<br>
> <br>
> Should you lose access to your 2FA device you can obtain a recovery<br>
> token to log back in via SSH, see<br>
> <a href="https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh" rel="noreferrer" target="_blank">https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh</a><br>
> for more details on this.<br>
> <br>
> Please let us know if there are any queries on the above.<br>
<br>
Hi,<br></blockquote><div><br></div><div>Hi Christoph,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
whereas I can see the security benefit, this raises the hurdle for one <br>
time<br>
contributors again a lot.<br>
<br>
Before you already had to register to get your merge request,<br>
now you need to setup this too (or at least soon it is mandatory).<br>
<br>
I am not sure this is such a good thing. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I see a point that one wants to avoid that e.g. somebody steals my <br>
account<br>
that has enough rights to delete all branches in the Kate repository via <br>
the<br>
web frontend.<br></blockquote><div><br></div><div>That is something you actually can't do - at least not entirely :)</div><div><br></div><div>Release branches are marked as protected within Gitlab, meaning that destructive operations will be blocked by Gitlab itself.</div><div>Even if this was to be permitted by Gitlab, our hooks would intervene and ensure a backup of the branch was taken immediately before it was deleted - making the damage an inconvenience only as nothing would be lost.</div><div><br></div><div>(See refs/backups/ in any Git repository on <a href="http://invent.kde.org">invent.kde.org</a>, these refs are also protected by the hooks so they cannot be harmed)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Could the 2FA stuff perhaps be limited to people with developer role or <br>
such? </blockquote><div><br></div><div>It is technically possible to only apply the mandatory 2FA rules to only certain groups as Developer accounts are simply membership in teams/kde-developers.</div><div>See <a href="https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group">https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group</a> for the documentation on this.</div><div><br></div><div>Given that we are using Invent for authenticating our various other services and the users of those aren't necessarily developers (while still having access to sensitive information) it seemed more prudent to enforce 2FA for everyone to ensure all our systems have a minimum baseline of industry best practice protection in place.</div><div><br></div><div>This also avoids any issue when people are granted a developer account and suddenly find themselves subject to a new requirement.</div><div><br></div><div>Thanks,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Greetings<br>
Christoph<br>
<br>
> <br>
> Thanks,<br>
> Ben<br>
> <br>
> Links:<br>
> ------<br>
> [1] <a href="http://invent.kde.org" rel="noreferrer" target="_blank">http://invent.kde.org</a><br>
<br>
-- <br>
Ignorance is bliss...<br>
<a href="https://cullmann.io" rel="noreferrer" target="_blank">https://cullmann.io</a> | <a href="https://kate-editor.org" rel="noreferrer" target="_blank">https://kate-editor.org</a><br>
</blockquote></div></div>
</div>