Re: Gitlab update, 2FA now mandatory
On 2022.10.26 16:33, Tobias Leupold wrote:
Am Montag, 24. Oktober 2022, 01:16:30 CEST schrieb Jack:
> On 2022.10.23 02:32, Ben Cooksley wrote:
> > Hi all,
> >
> > This afternoon I updated invent.kde.org 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_authentication.
> > html#generate-new-recovery-codes-using-ssh for more details on
this.
> >
> > Please let us know if there are any queries on the above.
> >
> > Thanks,
> > Ben
>
> Sorry to be dense, but without a webauthn token device, it seems
I'm at
> a total block if I don't have a phone (or don't have it with me.)
Is
> that correct, or is there some fine manual I need to read?
Just to take this up again, possibly for the more conservative folks
here:
I never had anything to do with Two-Factor-Authentication until now.
But
actually, it's not so complicated as it seems to be at first glance.
After having messed with it a bit, I found out that one doesn't have
to use a
phone to scan QR codes and such. The one-time-password used for
GitLab 2FA is
only derived from the "secret" (or "key", as GitLab calls it) and the
moment
in time where it should be used.
So you can e.g. store that key (it's displayed on GitLab below the QR
code, we
don't need the other stuff) in pass's db, e.g. in
var/invent.kde.org_2FA or
such.
With the help of a small shell script invoking pass and oathtool
(from oath-
toolkit), you can then retrieve the one-time-password by only using
the shell:
#!/bin/bash
secret=$(pass $1) # Get the key from pass's
db
secret=${secret// /}# Strip all spaces from it
valid=$((30 - 10#$(date +%S) % 30)) # Calculate the validity
otp=$(oathtool --base32 --totp $secret) # Generate the OTP
echo "$otp (valid ${valid}s)" # Print the result
Call it e.g. with the above var/invent.kde.org_2FA as the parameter,
and you
get (after having unlocked your PGP key of course) something like
111658 (valid 28s)
If the time the password will be valid is too short, you can simply
call it
again after some seconds (the PGP key stays unlocked for some time).
Of course, this has no error checking or such. But this could be
added quite
trivially. This way, we neither need some phone, nor some specialized
device
or app to deal with that OTP stuff, but only well-known console tools.
Maybe this helps somebody ;-)
Thanks. I might just try that.
I also found a KDE app called keysmith, but Gentoo doesn't package it,
so I don't quite know what to think of it. I've installed it, but not
yet tried to use it.
Jack
Cheers, Tobias
Re: Gitlab update, 2FA now mandatory
On 2022.10.23 02:32, Ben Cooksley wrote: Hi all, This afternoon I updated invent.kde.org 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_authentication.html#generate-new-recovery-codes-using-ssh for more details on this. Please let us know if there are any queries on the above. Thanks, Ben Sorry to be dense, but without a webauthn token device, it seems I'm at a total block if I don't have a phone (or don't have it with me.) Is that correct, or is there some fine manual I need to read? Thanks. Jack
Re: macOS, Hombrew and KAte
On 2022.07.18 13:30, Yoann LE BARS wrote:
Hello, everybody out there!
I am mostly used to Linux, but right now I have to use a
computer running macOS. I want to install Kate and KDEvelop on it – I
really like these tools, by the way, thank you for this very good job.
The DMG installer did work for Kate, but not for KDEvelop. So I
figured out I rather install them with Hombrew, and I have already
used it. I have installed KDE specific Hombrew repository
(https://invent.kde.org/packaging/homebrew-kde).
Then, I have uninstalled Kate and try to install it back, this
time using Homebrew, but I got the error given at the end of this
message. As I am quite new in using macOS, I must say I do not really
know what I should do. Can anyone help me?
Best regards.
The error message:
==> Installing kde-mac/kde/kate dependency:
kde-mac/kde/kf5-plasma-frame
==> Patching
==> Applying dff1b034c1162062aa2292099d3d01fc53dafdf6.diff
patching file CMakeLists.txt
Hunk #1 FAILED at 118.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
patching file src/declarativeimports/core/CMakeLists.txt
Hunk #1 FAILED at 70.
1 out of 1 hunk FAILED -- saving rejects to file
src/declarativeimports/core/CMakeLists.txt.rej
I don't use a Mac or Homebrew at all, but I'd say you need to start by
finding out why the patch doesn't apply cleanly. You can start by
looking in those reject files, although that might not really tell you
much. If there is a forum or mailing list or bugtracker for where you
get the homebrew recipe (is that even the right term?) I'd start by
looking there. It's possible the patches simply have not been updated
for the latest version of the plasma framework (kf5-plasma-frame).
Do not report this issue to Homebrew/brew or Homebrew/core!
Too bad it doesn't say where you CAN report it, but it means it's not a
bug in the homebrew software itself, but likely in the specific brew
for kf5-plasma-frame.
/opt/homebrew/Library/Homebrew/utils/github/api.rb:304:in
`raise_error': Validation Failed: [{"message"=>"The listed users and
repositories cannot be searched either because the resources do not
exist or you do not have permission to view them.",
"resource"=>"Search", "field"=>"q", "code"=>"invalid"}]
(GitHub::API::ValidationFailedError)
from /opt/homebrew/Library/Homebrew/utils/github/api.rb:234:in
`open_rest'
from /opt/homebrew/Library/Homebrew/utils/github.rb:173:in
`search'
from /opt/homebrew/Library/Homebrew/utils/github.rb:34:in
`search_issues'
from /opt/homebrew/Library/Homebrew/utils/github.rb:67:in
`issues_for_formula'
from /opt/homebrew/Library/Homebrew/exceptions.rb:486:in
`fetch_issues'
from /opt/homebrew/Library/Homebrew/exceptions.rb:482:in
`issues'
from /opt/homebrew/Library/Homebrew/exceptions.rb:536:in `dump'
from /opt/homebrew/Library/Homebrew/brew.rb:140:in `rescue in
'
from /opt/homebrew/Library/Homebrew/brew.rb:128:in `'
/opt/homebrew/Library/Homebrew/patch.rb:166:in `rescue in apply':
Failed executing: patch -g 0 -f -p1 -i
/private/tmp/kf5-plasma-framework--patch-20220718-58553-1gzz3dq/dff1b034c1162062aa2292099d3d01fc53dafdf6.diff
(BuildError)
from /opt/homebrew/Library/Homebrew/patch.rb:138:in `apply'
from /opt/homebrew/Library/Homebrew/formula.rb:1270:in `each'
from /opt/homebrew/Library/Homebrew/formula.rb:1270:in `patch'
from /opt/homebrew/Library/Homebrew/build.rb:144:in `block (3
levels) in install'
from /opt/homebrew/Library/Homebrew/utils.rb:601:in `with_env'
from /opt/homebrew/Library/Homebrew/build.rb:134:in `block (2
levels) in install'
from /opt/homebrew/Library/Homebrew/formula.rb:1286:in `block
in brew'
from /opt/homebrew/Library/Homebrew/formula.rb:2462:in `block
(2 levels) in stage'
from /opt/homebrew/Library/Homebrew/utils.rb:601:in `with_env'
from /opt/homebrew/Library/Homebrew/formula.rb:2461:in `block
in stage'
from /opt/homebrew/Library/Homebrew/resource.rb:130:in `block
(2 levels) in unpack'
from /opt/homebrew/Library/Homebrew/download_strategy.rb:115:in
`chdir'
from /opt/homebrew/Library/Homebrew/download_strategy.rb:115:in
`chdir'
from /opt/homebrew/Library/Homebrew/download_strategy.rb:102:in
`stage'
from /opt/homebrew/Library/Homebrew/resource.rb:126:in `block
in unpack'
from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `block in
run'
from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `chdir'
from /opt/homebrew/Library/Homebrew/mktemp.rb:63:in `run'
from /opt/homebrew/Library/Homebrew/resource.rb:239:in `mktemp'
from /opt/homebrew/Library/Homebrew/resource.rb:125:in `unpack'
from /opt/homebrew/Library/Homebrew/resource.rb:99:in `stage'
from
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/forwardable.rb:230:in
`stage'
from /opt/homebrew/Library/Homebrew/formula.rb:2441:in `stage'
Re: KDE Apps name trademarks
On 2020.07.08 14:20, Ben Cooksley wrote: On Thu, Jul 9, 2020 at 6:09 AM Christoph Cullmann wrote: > > On 2020-07-08 18:12, Jonathan Riddell wrote: > > Recently we've noticed some KDE apps ending up on the Microsoft Store > > uploaded by unknown third parties. Maybe to up some credit score for > > their developer account. Maybe to install bitcoin miners. We don't > > know the motivations. Since it's all free software the licence allows > > it. > > Hi, > > have you some links to these applications? I believe Jonathan will be referring to https://www.microsoft.com/en-gb/p/kdiff-3-diff-utility/9ndvvx243rfh?activetab=pivot:overviewtab# If I follow that link, and click for the US version, I see KDiff3 for sale at $4.99. Does the license actually allow charging? (I wonder how that is split between MS and the uploader.) I know you can charge for media, but this is download, so no media. It also doesn't seem to mention anything about where the source code is available. I don't see any mention of KDE at all, but I suppose that is legal. I'm curious what happens if someone buys this, and then needs help. Do they go to the uploader? I doubt it. Do they go to Microsoft? I doubt it. If the program hasn't been modified by the uploader to point to a different source of help, it probably points back to KDE. If KDE does officially upload anything to the Window Store, should we just upload an official version whenever we see this happen? > > One option is to claim Trademark on all our app names. This isn't > > hard, we just add the ™ onto the name anywhere we have it on our > > website starting with kde.org/applications [1]. Some apps such as > > KOffice have done this in the past anyway. This doesn't cost > > anything, only a registered trademark (which uses the ®. logo) costs > > money. It might give us more ability to take down random people > > posting our software on app stores. It might also make us look more > > corporate than we want to look and put off Linux distros from shipping > > our software. > > > > Should we add ™ next to the app names? > > As other already posted, I don't think this is sufficient nor do I think > that is really the direction we should move to. (at least for Kate, I am > fine with the status quo). I concur with that sentiment.
Re: Tuxedo's house (Re: New kde.org/hardware webpage)
On 1/26/20 11:51 AM, Philippe Cloutier wrote: Hi Ingo, Nate, Le 2020-01-26 à 11:21, Nate Graham a écrit : On 1/26/20 9:16 AM, Ingo Klöcker wrote: On Freitag, 24. Januar 2020 15:02:24 CET Philippe Cloutier wrote: Ahem, wasn't that fast? The mail you quote is not phrased as a proposal, but as a request for comments. Just a quick first look reveals at least the following issues: The currency units used are unclear. Tuxedo build tailor-made hardware and all this with Linux! I suppose s/build/builds/ All the computers and notebooks are assembled and installed in our house. "our house"? "in our house" means in the house/building were Tuxedo Computers resides. As opposed to "are assembled and installed in a sweat shop in some cheap-labor- country". Ah, English is not my native language, but that was certainly based on the English expression "in house", documented on https://en.wiktionary.org/wiki/in_house Thank you To avoid confusion, you might say " made in-house by Tuxedo, not outsourced." or to be more specific and informative, "made in-house by Tuxedo in (country), not outsourced." Jack Regards, Ingo since the text is on KDE.org, using the word "our" makes it unclear whose house the laptop is being assembled in though. KDE's house? Indeed It should probably say, "[...] assembled and installed in-house." Or even, "[...] assembled and installed in-house, not outsourced." to really drive the point home. Indeed. Some more remarks on that sentence: 1. "the computers and notebooks" sounds odd (unless Tuxedo assembles paper notebooks). 2. It is strange to dedicate 1 sentence out of 5 to this topic. I mean: 1. Is assembly and installation even a significant part of the work involved in building a PC? 2. Unless we add content describing the enterprise, readers won't even know what Tuxedo is and have any idea what are its labor conditions. 3. "installing a computer in a house" sounds like me bringing a computer to my friend's house and plugging in the power and all the other wires. I imagine what was intended was "installing software on a computer". [...] Nate -- Philippe Cloutier http://www.philippecloutier.com
Re: Sysadmin Load Reduction: Subversion Infrastructure
On 11/12/19 7:11 AM, Luigi Toscano wrote: Māris Nartišs ha scritto: pirmd., 2019. g. 11. nov., plkst. 16:02 — lietotājs Luigi Toscano () rakstīja: Alexander Potashev ha scritto: вс, 10 нояб. 2019 г. в 18:09, Luigi Toscano : Nate Graham ha scritto: On 11/9/19 4:50 PM, Nicolás Alvarez wrote: El sáb., 9 de nov. de 2019 a la(s) 20:29, Nate Graham (n...@kde.org) escribió: - Experiment conversion to git and see if the resulting repo(s) are of a reasonable size (I vaguely recall seeing bad results with this) I expect that a single Git repository would be several GBs in size. For the record, the current checkout (without svn metadata) of trunk/l10n-kde4 (ok, no more needed), branches/stable/l10n-kde4, branches/stable/l10n-kf5, branches/stable/l10n-kf5-plasma-lts, trunk/l10n-kf5 and trunk/l10n-summit is ~11 GiB. The trunk/l10n-kf5 branch alone is 5.3 GiB. One of pro sides of SVN still is ability to work with a single directory instead of whole repo. For Latvian language it means using only ~300MB of disk space (I have less than 1GB free space on my laptop). Thus if a move to GIT is planned, I would vote to have a separate repo for each language. Right, but that would make the life of people doing bulk changes (like me) much more complicated. Right now I can do all the changes in one shot. That's part of the problem. Would git submodules help with this? I can imagine it would be an effort to get it set up, but then you have everything in one place. Jack
Re: vote invitation sent out for goal voting
On 2019.08.23 00:24, Nicolás Alvarez wrote: El jue., 22 de ago. de 2019 a la(s) 22:13, Myriam Schweingruber (myr...@kde.org) escribió: > Any particular reason I got this survey request twice? That gives me technically two votes, so there might be something wrong, especially if I am not the only one who got this twice. Did you get them on the same email address? Lydia sent it to all developers and all mailing list subscribers. Maybe your developer account and your mailing list subscription have different addresses, so you got one on each. -- Nicolás I also got two sent to the same address. Near as I can tell, they are identical except for the token to the survey. Jack
