Re: Gitlab update, 2FA now mandatory

2022-10-25 Thread David Jarvie
On 25 October 2022 11:19:36 BST, Dan Leinir Turthra Jensen  
wrote:
> On Tuesday, 25 October 2022 11:11:46 BST Carl Schwan wrote:
> > Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (cullmann.io) 
>  a écrit :
> > > On 2022-10-23 08:32, Ben Cooksley wrote:
> > > > Hi all,
> > > > 
> > > > This afternoon I updated invent.kde.org [1] to the latest version of
> > > > Gitlab, 15.5.
> > > > Release notes for this can be found at
> > > > https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/
> > > > 
> > > > There isn't much notable feature wise in this release, however there
> > > > have been some bug fixes surrounding the "Rebase without Pipeline"
> > > > functionality that was introduced in an earlier update.
> > > > 
> > > > As part of securing Invent against recently detected suspicious
> > > > activity I have also enabled Mandatory 2FA, which Gitlab will ask you
> > > > to configure next time you access it. This can be done using either a
> > > > Webauthn token (such as a Yubikey) or TOTP (using the app of choice on
> > > > your phone)
> > > > 
> > > > Should you lose access to your 2FA device you can obtain a recovery
> > > > token to log back in via SSH, see
> > > > https://docs.gitlab.com/ee/user/profile/account/two_factor_authenticatio
> > > > n.html#generate-new-recovery-codes-using-ssh for more details on this.
> > > > 
> > > > Please let us know if there are any queries on the above.
> > > 
> > > Hi,
> > > 
> > > whereas I can see the security benefit, this raises the hurdle for one
> > > time contributors again a lot.
> > > 
> > > Before you already had to register to get your merge request,
> > > now you need to setup this too (or at least soon it is mandatory).
> > > 
> > > I am not sure this is such a good thing.
> > > 
> > > I see a point that one wants to avoid that e.g. somebody steals my
> > > account  that has enough rights to delete all branches in the Kate
> > > repository via the web frontend.
> > > 
> > > Could the 2FA stuff perhaps be limited to people with developer role or
> > > such?
> > 
> > Yes this would be ideal. We don't need to require 2fa for people who just
> > started contributing or want to give some feedback on a MR/ticket.
> > 
> > This should be possible with the following features:
> > https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2
> > fa-for-all-users-in-a-group
> > 
> > We can just require 2fa for developers because with great powers come great
> > responsibilities.
> > 
> > Cheers,
> > Carl
> 
>   i concur - after spending so long trying to attract casual contributors, 
> putting up a huge barrier like this is just not helpful. So, 2FA for people 
> who area able to actually mess stuff up, absolutely, we have responsibility 
> here and that's fine, but for casual contributors, that is precisely the sort 
> of thing that just outright makes people go "lol no" and go away again, and 
> is 
> that really something we can afford?
>   I absolutely applaud the attempt at increasing out trustworthiness as a 
> community, and 2FA for people who can actually push things certainly helps us 
> get to that, but i also can't help but notice that the particular choice of 
> making it a blanket community involvement requirement, that is, in this 
> particular case, was made with a somewhat narrow focus, so... just thought 
> i'd 
> lend my voice to the "Yeah, please don't make our hard won casual 
> contributors 
> go away before they even get here".
> 

I agree. Anybody without a real commitment to KDE would be likely to be put off 
by this requirement.

I also concur with Frederik, that there are people who have no previous 
exposure to this form of 2FA. The only form of 2FA which I have previously 
encountered is by text to my mobile phone. I had no idea that apps for this 
purpose existed. Because I develop KDE software, I have the motivation to find 
out how to set up 2FA for invent. But if I was a casual user, there is no way 
that I'd be prepared to spend the time and effort investigating how to do it. 
It's far too big a hurdle for somebody such as me who's not already committed 
to the project.
--
David Jarvie
KAlarm author, KDE developer


Re: Improving Bugzilla Status Names

2018-09-30 Thread David Jarvie


On 28 September 2018 09:48:42 BST, Luigi Toscano  
wrote:
>Kai Uwe Broulik ha scritto:
>> Hi,
>> 
>>  > Here is my follow-up change recommendation based on feedback and
>research:
>>  >
>>  > UNCONFIRMED -> REPORTED
>>  > WONTFIX -> INTENTIONAL
>>  > INVALID -> NOTABUG
>> 
>> one issue I'm having with "REPORTED" is that it shows up as "REPO" in
>the list 
>> and can easily be confused with "REOP" for "REOPENED". Perhaps we
>need 
>> something different for Reopened then.
>
>If we rename also that, we would have two bug names diverging from the
>other 
>bug trackers, instead of just one. Moreover I find that there is no
>much to 
>discuss on the appropriateness of REOPENED.
>I'd rather find an alternative for REPORTED, if this confusion is going
>to be 
>an issue.
>
>-- 
>Luigi

I think that REPORTED is an ideal term for a newly opened bug. Is there really 
a problem with the abbreviations REPO and REOP? Surely people will quickly get 
used to making the distinction, if they make a mistake at all. In any case, as 
soon as the bug report is accessed, it will be clear what its status is. Please 
keep REPORTED and REOPENED as they are.

--
David Jarvie
KAlarm author, KDE developer
http://www.astrojar.org.uk/kalarm


Re: [kde-community] finding a clear vision for KDE - final version

2016-03-15 Thread David Jarvie
On 15 March 2016 21:15:38 GMT+00:00, Alexander Neundorf <neund...@kde.org> 
wrote:
>On Tuesday, March 15, 2016 08:26:15 Stephen Kelly wrote:
>> Lydia Pintscher wrote:
>> > Hi everyone,
>> > 
>> > "A world in which everyone enjoys freedom and privacy and has
>control
>> > over their digital life."
>> > 
>> > Unless there are major objections within the next week I would like
>to
>> > conclude the process and from now on use this as our vision
>statement.
>> 
>> Not a major objection, but some feedback: It's very wordy at the end
>> especially with all the 'and's in it.
>
>I agree, the two "and"'s sound a bit bumpy/"holprig".
>
>I very much like that freedom is in there, this fit's my wish to
>express some 
>kind of independence.
>How about skipping the "privacy" ? This is with no or only very little 
>interpretation included in "have control".


This may read a bit better, although it does slightly alter the emphasis:

"A world in which everyone has control over their digital life and enjoys 
freedom and privacy."

--
David Jarvie
KAlarm author, KDE developer
http://www.astrojar.org.UK/KAlarm
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

Re: [kde-community] Renaming KScreenGenie

2015-09-20 Thread David Jarvie
Selfie suggests that it would use a webcam to take a picture. A misleading name 
is not a good name IMHO.

On 19 September 2015 20:08:06 BST, Rajeev Bhatta <techie.raj...@yahoo.in> wrote:
>Selfie is better than Kapture for sure.. :)
>
>On Saturday, September 19, 2015 08:38:41 PM Eike Hein wrote:
>> On 09/19/2015 08:32 PM, Rajeev Bhatta wrote:
>> > If we can choose the name Selfie and then it is important to have
>the
>> > users
>> > relate to it as a product too then it works, if we cannot target
>that then
>> > we should not name it such...
>> 
>> I feel like Selfie is more likely to create an emotional
>> bond than Kapture. That's a gut feeling; it's hard to
>> substantiate.
>> 
>> 
>> Cheers,
>> Eike
>
>_______
>kde-community mailing list
>kde-community@kde.org
>https://mail.kde.org/mailman/listinfo/kde-community

--
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm
___
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community