Re: Inactive packagers to be removed after the F37 release

[Benson Muite]

On 12/2/22 14:04, Vít Ondruch wrote:


Dne 02. 12. 22 v 8:00 Benson Muite napsal(a):



- rpms/ruby-ncurses

Taken



Why? It does not deserve to live, at least in its current (abandoned and 
deprecated) form.



Thanks for the warning. Orphaned it.


Vít


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 02. 12. 22 v 8:00 Benson Muite napsal(a):



- rpms/ruby-ncurses

Taken



Why? It does not deserve to live, at least in its current (abandoned and 
deprecated) form.



Vít



- rpms/ucx

Taken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Benson Muite]

- rpms/ruby-ncurses

Taken

- rpms/ucx

Taken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Mon, 2022-11-28 at 15:00 -0800, Adam Williamson wrote:
> On Mon, 2022-11-28 at 19:24 +, Artur Frenszek-Iwicki wrote:
> > > - rpms/fpc
> > > - rpms/lazarus
> > I've been a co-admin on those, so I took 'em.
> > 
> > Several of the orphaned packages are dependencies of stuff I
> > currently maintain.
> > I'll wait a week or two to see if anyone else wants to take them.
> 
> Same here, specifically python-requests-oauthlib and python-
> resultsdb_api (I might take resultsdb_api sooner as it's kinda in our
> wheelhouse).

I've taken python-resultsdb_api .
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[arthur]

On 28/11/2022 19:20, Mattia Verga via devel wrote:

- rpms/thefuck

Took it since I was a co-admin


- rpms/vim-latex


Took this as well

--
Arthur Bols
fas/irc: principis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

and the orphans packages ? Re: Inactive packagers to be removed after the F37 release

[Sérgio Basto]

On Tue, 2022-11-29 at 10:04 -0600, Nick Bebout wrote:
> For some reason a few people weren't processed - I ran the script
> over them again and most were successful.
> For some reason, mmorsi causes the script to traceback (and zodbot
> errors trying to .fasinfo them as well).  I processed mmorsi by hand.
> If anyone notices any others that got missed, please let me know.
> 


I don't know if you are aware but orphans.txt report is which generated
with script find_unblocked_orphans.py, now have the date and seems it
is updated every 3 hours, so we can known what orphans and dependencies
problems do we have with [1], the result so far is [2] , i.e, if you
took one package, after 3 hours you can see the result . 

I took some packages [3], my choices was almost dinosaurs that have
leaved without maintainers, to see what's left ... 


[1]
wget https://churchyard.fedorapeople.org/orphans.txt -O - -q | grep -e
"Depending on:" -e ^Report

[2]
Report started at 2022-12-01 18:26:22 UTC
Depending on: CheMPS2 (2), status change: 2022-11-28 (0 weeks ago)
Depending on: abiword (1), status change: 2022-11-28 (0 weeks ago)
Depending on: alure (3), status change: 2022-11-28 (0 weeks ago)
Depending on: blackbox (1), status change: 2022-11-28 (0 weeks ago)
Depending on: bluecurve-gtk-themes (1), status change: 2022-11-29 (0
weeks ago)
Depending on: bluecurve-icon-theme (1), status change: 2022-11-29 (0
weeks ago)
Depending on: bluecurve-metacity-theme (1), status change: 2022-11-29
(0 weeks ago)
Depending on: dmz-cursor-themes (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: enchant (26), status change: 2022-11-28 (0 weeks ago)
Depending on: fcitx (17), status change: 2022-11-28 (0 weeks ago)
Depending on: golang-github-containerd-stargz-snapshotter (21), status
change: 2022-11-08 (3 weeks ago)
Depending on: golang-github-fvbommel-sortorder (25), status change:
2022-11-08 (3 weeks ago)
Depending on: golang-github-gocomply-scap (1), status change: 2022-11-
28 (0 weeks ago)
Depending on: golang-github-google-containerregistry (2), status
change: 2022-11-08 (3 weeks ago)
Depending on: golang-github-hanwen-fuse (28), status change: 2022-11-08
(3 weeks ago)
Depending on: golang-github-mitchellh-cli (28), status change: 2022-11-
28 (0 weeks ago)
Depending on: golang-github-pkg-browser (3), status change: 2022-11-28
(0 weeks ago)
Depending on: golang-github-spaolacci-murmur3 (4), status change: 2022-
11-28 (0 weeks ago)
Depending on: golang-github-tonistiigi-rosetta (24), status change:
2022-11-08 (3 weeks ago)
Depending on: gtkhtml3 (1), status change: 2022-12-01 (0 weeks ago)
Depending on: hunspell-kn (12), status change: 2022-11-28 (0 weeks ago)
Depending on: ibus-table-others (36), status change: 2022-11-28 (0
weeks ago)
Depending on: jargs (1), status change: 2022-11-28 (0 weeks ago)
Depending on: jcodings (1), status change: 2022-11-28 (0 weeks ago)
Depending on: jffi (3), status change: 2022-11-28 (0 weeks ago)
Depending on: jnr-constants (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: jnr-ffi (2), status change: 2022-11-28 (0 weeks ago)
Depending on: jnr-x86asm (3), status change: 2022-11-28 (0 weeks ago)
Depending on: libannodex (1), status change: 2022-11-28 (0 weeks ago)
Depending on: libbonobo (21), status change: 2022-11-29 (0 weeks ago)
Depending on: libbonoboui (21), status change: 2022-11-29 (0 weeks ago)
Depending on: libcmml (2), status change: 2022-11-28 (0 weeks ago)
Depending on: libcmpiutil (1), status change: 2022-11-28 (0 weeks ago)
Depending on: libgnome (21), status change: 2022-11-29 (0 weeks ago)
Depending on: libgnomeui (21), status change: 2022-11-29 (0 weeks ago)
Depending on: libmacaroons (12), status change: 2022-11-28 (0 weeks
ago)
Depending on: libpmemobj-cpp (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: librcd (2), status change: 2022-11-28 (0 weeks ago)
Depending on: libstroke (2), status change: 2022-11-28 (0 weeks ago)
Depending on: libusbauth-configparser (2), status change: 2022-11-28 (0
weeks ago)
Depending on: maloc (2), status change: 2022-11-28 (0 weeks ago)
Depending on: maven-scm (22), status change: 2022-11-28 (0 weeks ago)
Depending on: mediawiki-validator (1), status change: 2022-11-28 (0
weeks ago)
Depending on: mingw-dbus (37), status change: 2022-11-28 (0 weeks ago)
Depending on: mingw-pcre (35), status change: 2022-11-28 (0 weeks ago)
Depending on: mingw-xerces-c (34), status change: 2022-11-28 (0 weeks
ago)
Depending on: moarvm (8), status change: 2022-11-28 (0 weeks ago)
Depending on: nqp (7), status change: 2022-11-28 (0 weeks ago)
Depending on: nvml (44), status change: 2022-11-28 (0 weeks ago)
Depending on: openjpeg (5), status change: 2022-11-28 (0 weeks ago)
Depending on: perl-File-KeePass (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: perl-Goo-Canvas (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: perl-MARC-Charset (1), status change: 2022-11-28 (0 weeks
ago)
Depending on: perl-PFT (1), status change: 2022-11-28 

Re: Inactive packagers to be removed after the F37 release

[Miroslav Suchý]

Dne 28. 11. 22 v 19:20 Mattia Verga via devel napsal(a):

- rpms/python-copr-common
- rpms/python-flask-whooshee


Taken.

M.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Nick Bebout]

For some reason a few people weren't processed - I ran the script over them
again and most were successful.
For some reason, mmorsi causes the script to traceback (and zodbot errors
trying to .fasinfo them as well).  I processed mmorsi by hand.
If anyone notices any others that got missed, please let me know.

orphaned (that previously had mmorsi as main admin):
rubygem-abstract
rubygem-actionmailer
rubygem-actionpack
rubygem-activerecord
rubygem-activeresource
rubygem-activesupport
rubygem-archive-tar-minitar
rubygem-memcache-client
rubygem-mime-types
rubygem-minitest
rubygem-more_core_extensions
rubygem-rails
rubygem-rdoc
rubygem-ruby-hmac
rubygem-sass
rubygem-scruffy
rubygem-sexp_processor
rubygem-syntax
rubygem-thor
rubygem-uuidtools
rubygem-webmock
rubygem-yard
rubygem-ZenTest

jehane is watching rpms/fusioninventory-agent
jehane is no longer watching rpms/fusioninventory-agent
jehane is watching rpms/perl-HTTP-Server-Simple-Authen
jehane is no longer watching rpms/perl-HTTP-Server-Simple-Authen
jehane is watching rpms/perl-POE-Component-Client-Ping
jehane is no longer watching rpms/perl-POE-Component-Client-Ping
jehane is watching rpms/perl-Parse-EDID
jehane is no longer watching rpms/perl-Parse-EDID
jehane is watching rpms/perl-Proc-PID-File
jehane is no longer watching rpms/perl-Proc-PID-File
jehane is watching rpms/perl-Test-POE-Server-TCP
jehane is no longer watching rpms/perl-Test-POE-Server-TCP
jehane is maintainer of rpms/perl-XML-TreePP
jehane is no longer maintaining rpms/perl-XML-TreePP
jehane is no longer watching rpms/perl-XML-TreePP

skottler is maintainer of rpms/rubygem-mocha
skottler is no longer maintaining rpms/rubygem-mocha
skottler is no longer watching rpms/rubygem-mocha

ivazquez is watching rpms/django-contact-form
ivazquez is no longer watching rpms/django-contact-form
ivazquez is watching rpms/django-evolution
ivazquez is no longer watching rpms/django-evolution
ivazquez is watching rpms/django-notification
ivazquez is no longer watching rpms/django-notification
ivazquez is watching rpms/django-pagination
ivazquez is no longer watching rpms/django-pagination
ivazquez is watching rpms/django-sct
ivazquez is no longer watching rpms/django-sct
ivazquez is watching rpms/django-tagging
ivazquez is no longer watching rpms/django-tagging
ivazquez is watching rpms/feh
ivazquez is no longer watching rpms/feh
ivazquez is watching rpms/leafpad
ivazquez is no longer watching rpms/leafpad
ivazquez is maintainer of rpms/libtool
ivazquez is no longer maintaining rpms/libtool
ivazquez is no longer watching rpms/libtool
ivazquez is watching rpms/mod_auth_pam
ivazquez is no longer watching rpms/mod_auth_pam
ivazquez is watching rpms/mod_dnssd
ivazquez is no longer watching rpms/mod_dnssd
ivazquez is maintainer of rpms/moin
ivazquez is no longer maintaining rpms/moin
ivazquez is no longer watching rpms/moin
ivazquez is maintainer of rpms/purple-plugin_pack
ivazquez is no longer maintaining rpms/purple-plugin_pack
ivazquez is no longer watching rpms/purple-plugin_pack
ivazquez is maintainer of rpms/python-paramiko
ivazquez is no longer maintaining rpms/python-paramiko
ivazquez is no longer watching rpms/python-paramiko
ivazquez is maintainer of rpms/python-polib
ivazquez is no longer maintaining rpms/python-polib
ivazquez is no longer watching rpms/python-polib
ivazquez is maintainer of rpms/python-sqlalchemy
ivazquez is no longer maintaining rpms/python-sqlalchemy
ivazquez is no longer watching rpms/python-sqlalchemy
ivazquez is maintainer of rpms/pywebkitgtk
ivazquez is no longer maintaining rpms/pywebkitgtk
ivazquez is no longer watching rpms/pywebkitgtk
ivazquez is watching rpms/transifex
ivazquez is no longer watching rpms/transifex
ivazquez is maintainer of rpms/xmlcopyeditor
ivazquez is no longer maintaining rpms/xmlcopyeditor
ivazquez is no longer watching rpms/xmlcopyeditor
ivazquez is watching rpms/xmlroff
ivazquez is no longer watching rpms/xmlroff

fredlima is maintainer of rpms/golang-github-chaseadamsio-goorgeous
fredlima is no longer maintaining rpms/golang-github-chaseadamsio-goorgeous
fredlima is no longer watching rpms/golang-github-chaseadamsio-goorgeous
fredlima is maintainer of rpms/golang-github-dchest-cssmin
fredlima is no longer maintaining rpms/golang-github-dchest-cssmin
fredlima is no longer watching rpms/golang-github-dchest-cssmin
fredlima is maintainer of rpms/golang-github-eknkc-amber
fredlima is no longer maintaining rpms/golang-github-eknkc-amber
fredlima is no longer watching rpms/golang-github-eknkc-amber
fredlima is maintainer of rpms/golang-github-fortytw2-leaktest
fredlima is no longer maintaining rpms/golang-github-fortytw2-leaktest
fredlima is no longer watching rpms/golang-github-fortytw2-leaktest
fredlima is watching rpms/golang-github-miekg-mmark
fredlima is no longer watching rpms/golang-github-miekg-mmark
fredlima is maintainer of rpms/golang-github-spf13-nitro
fredlima is no longer maintaining rpms/golang-github-spf13-nitro
fredlima is no longer 

Re: Inactive packagers to be removed after the F37 release

[Anderson Sasaki]

Hello,

I'll take:

- rpms/keylime

Thank you,
Anderson
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Mattia Verga via devel]

Il 29/11/22 11:16, Vít Ondruch ha scritto:
>
>
> Dne 29. 11. 22 v 11:05 Vít Ondruch napsal(a):
>>
>>
>> Dne 29. 11. 22 v 11:02 Vít Ondruch napsal(a):
>>>
>>>
>>> Dne 29. 11. 22 v 10:46 Vít Ondruch napsal(a):

 I don't think that this went completely correct. I have just
 claimed ownership of rubygem-em-socksify (so far so good). However,
 I noticed, that mmorsi, while removed from packager group (at least
 being on the list)

>>>
>>> Just checked that he is not member of packager group anymore,
>>> therefore he should have been completely removed from all packages,
>>> not just being removed where he was the main POC.
>>>
>>
>> And there are still packages owned by mmorsi:
>>
>>
>> https://src.fedoraproject.org/rpms/rubygem-thor
>>
>>
>> Vít
>>
>>
>
> Even the log is weird around mmorsi, intermixed with other maintainers.
>
>
> Vít
>
Some users didn't have their commit rights properly removed, it seems.

I've opened a ticket on infra:
https://pagure.io/fedora-infrastructure/issue/11015

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 28/11/2022 19:20, Mattia Verga via devel wrote:

- rpms/jdns
- rpms/tesseract
- rpms/zimlib
- rpms/pidgin-privacy-please
- rpms/yaml-cpp


Took these packages.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Paul Howarth]

On Tue, 29 Nov 2022 10:27:56 +
Paul Howarth  wrote:

> On Mon, 28 Nov 2022 18:20:20 +
> Mattia Verga via devel  wrote:
> 
> > Il 28/11/22 18:36, Nick Bebout ha scritto:
> >   
> > > I've removed a lot of ACLs. See attached log file.
> > 
> > Thanks Nick.
> > 
> > From your output I made a list of the orphaned packages which I
> > think it's a bit more readable:
> >   
> ...
> > - rpms/perl-App-PFT
> > - rpms/perl-Clipboard
> > - rpms/perl-Crypt-Rijndael  
> 
> I took perl-Crypt-Rijndael

And then I noticed that existing co-maintainer xavierb had been
defacto-maintaining it since 2020 so I gave it to him.

Regards, Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Paul Howarth]

On Mon, 28 Nov 2022 18:20:20 +
Mattia Verga via devel  wrote:

> Il 28/11/22 18:36, Nick Bebout ha scritto:
> 
> > I've removed a lot of ACLs. See attached log file.  
> 
> Thanks Nick.
> 
> From your output I made a list of the orphaned packages which I think
> it's a bit more readable:
> 
...
> - rpms/perl-App-PFT
> - rpms/perl-Clipboard
> - rpms/perl-Crypt-Rijndael

I took perl-Crypt-Rijndael

Regards, Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 29. 11. 22 v 11:05 Vít Ondruch napsal(a):



Dne 29. 11. 22 v 11:02 Vít Ondruch napsal(a):



Dne 29. 11. 22 v 10:46 Vít Ondruch napsal(a):


I don't think that this went completely correct. I have just claimed 
ownership of rubygem-em-socksify (so far so good). However, I 
noticed, that mmorsi, while removed from packager group (at least 
being on the list)




Just checked that he is not member of packager group anymore, 
therefore he should have been completely removed from all packages, 
not just being removed where he was the main POC.




And there are still packages owned by mmorsi:


https://src.fedoraproject.org/rpms/rubygem-thor


Vít




Even the log is weird around mmorsi, intermixed with other maintainers.


Vít





Vít


is still comaintainer of the package. I would assume that these 
people should have been completely dropped from the packages, 
shouldn't they?



Vít


Dne 28. 11. 22 v 18:36 Nick Bebout napsal(a):

I've removed a lot of ACLs.  See attached log file.

On Mon, Nov 28, 2022 at 9:51 AM Nick Bebout  wrote:

I have removed these accounts from the packager group, and am
currently running a script to remove their ACLs.  I will post
on devel list when it is complete (along with the packages that
are orphaned)

On Sat, Nov 26, 2022 at 2:05 AM Mattia Verga via devel
 wrote:

Il 24/11/22 09:38, Vít Ondruch ha scritto:
> @Ben isn't it the time to finish this round?
>
>
> Vít
>
>
It's being worked on in
https://pagure.io/fedora-infrastructure/issue/11002

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 29. 11. 22 v 11:02 Vít Ondruch napsal(a):



Dne 29. 11. 22 v 10:46 Vít Ondruch napsal(a):


I don't think that this went completely correct. I have just claimed 
ownership of rubygem-em-socksify (so far so good). However, I 
noticed, that mmorsi, while removed from packager group (at least 
being on the list)




Just checked that he is not member of packager group anymore, 
therefore he should have been completely removed from all packages, 
not just being removed where he was the main POC.




And there are still packages owned by mmorsi:


https://src.fedoraproject.org/rpms/rubygem-thor


Vít




Vít


is still comaintainer of the package. I would assume that these 
people should have been completely dropped from the packages, 
shouldn't they?



Vít


Dne 28. 11. 22 v 18:36 Nick Bebout napsal(a):

I've removed a lot of ACLs.  See attached log file.

On Mon, Nov 28, 2022 at 9:51 AM Nick Bebout  wrote:

I have removed these accounts from the packager group, and am
currently running a script to remove their ACLs.  I will post on
devel list when it is complete (along with the packages that are
orphaned)

On Sat, Nov 26, 2022 at 2:05 AM Mattia Verga via devel
 wrote:

Il 24/11/22 09:38, Vít Ondruch ha scritto:
> @Ben isn't it the time to finish this round?
>
>
> Vít
>
>
It's being worked on in
https://pagure.io/fedora-infrastructure/issue/11002

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 29. 11. 22 v 0:00 Adam Williamson napsal(a):

On Mon, 2022-11-28 at 19:24 +, Artur Frenszek-Iwicki wrote:

- rpms/fpc
- rpms/lazarus

I've been a co-admin on those, so I took 'em.

Several of the orphaned packages are dependencies of stuff I
currently maintain.
I'll wait a week or two to see if anyone else wants to take them.

Same here, specifically python-requests-oauthlib and python-
resultsdb_api (I might take resultsdb_api sooner as it's kinda in our
wheelhouse). Another one that somebody should definitely take is
libcomps (everything breaks if that goes away).

There are several chains through qemu which show up in a lot of my
packages:


qemu -> glusterfs -> pcs -> rubygem-sinatra -> rubygem-rdiscount (unmaintained)



I have claimed rubygem-rdiscount.


Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 29. 11. 22 v 10:46 Vít Ondruch napsal(a):


I don't think that this went completely correct. I have just claimed 
ownership of rubygem-em-socksify (so far so good). However, I noticed, 
that mmorsi, while removed from packager group (at least being on the 
list)




Just checked that he is not member of packager group anymore, therefore 
he should have been completely removed from all packages, not just being 
removed where he was the main POC.



Vít


is still comaintainer of the package. I would assume that these people 
should have been completely dropped from the packages, shouldn't they?



Vít


Dne 28. 11. 22 v 18:36 Nick Bebout napsal(a):

I've removed a lot of ACLs.  See attached log file.

On Mon, Nov 28, 2022 at 9:51 AM Nick Bebout  wrote:

I have removed these accounts from the packager group, and am
currently running a script to remove their ACLs.  I will post on
devel list when it is complete (along with the packages that are
orphaned)

On Sat, Nov 26, 2022 at 2:05 AM Mattia Verga via devel
 wrote:

Il 24/11/22 09:38, Vít Ondruch ha scritto:
> @Ben isn't it the time to finish this round?
>
>
> Vít
>
>
It's being worked on in
https://pagure.io/fedora-infrastructure/issue/11002

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 28. 11. 22 v 19:20 Mattia Verga via devel napsal(a):

Il 28/11/22 18:36, Nick Bebout ha scritto:

I've removed a lot of ACLs.  See attached log file.



Thanks Nick.

From your output I made a list of the orphaned packages which I think 
it's a bit more readable:



- rpms/rubygem-chronic
- rpms/rubygem-curb
- rpms/rubygem-em-socksify
- rpms/rubygem-mocha
- rpms/rubygem-net-ssh
- rpms/rubygem-rdiscount
- rpms/rubygem-rr



I have claimed these ^^




- rpms/rubygem-kgio



This one ^^ is in some zombie state:

https://pagure.io/releng/issue/11156


Vít



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

I don't think that this went completely correct. I have just claimed 
ownership of rubygem-em-socksify (so far so good). However, I noticed, 
that mmorsi, while removed from packager group (at least being on the 
list) is still comaintainer of the package. I would assume that these 
people should have been completely dropped from the packages, shouldn't 
they?



Vít


Dne 28. 11. 22 v 18:36 Nick Bebout napsal(a):

I've removed a lot of ACLs.  See attached log file.

On Mon, Nov 28, 2022 at 9:51 AM Nick Bebout  wrote:

I have removed these accounts from the packager group, and am
currently running a script to remove their ACLs.  I will post on
devel list when it is complete (along with the packages that are
orphaned)

On Sat, Nov 26, 2022 at 2:05 AM Mattia Verga via devel
 wrote:

Il 24/11/22 09:38, Vít Ondruch ha scritto:
> @Ben isn't it the time to finish this round?
>
>
> Vít
>
>
It's being worked on in
https://pagure.io/fedora-infrastructure/issue/11002

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue


___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Gary Buhrmaster]

On Mon, Nov 28, 2022 at 11:01 PM Adam Williamson
 wrote:

> qemu -> ceph -> openssh -> libfido2 -> libcbor (unmaintained)

I'll pick up libcbor, as I am the packager for libfido2.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Mon, 2022-11-28 at 19:24 +, Artur Frenszek-Iwicki wrote:
> > - rpms/fpc
> > - rpms/lazarus
> I've been a co-admin on those, so I took 'em.
> 
> Several of the orphaned packages are dependencies of stuff I
> currently maintain.
> I'll wait a week or two to see if anyone else wants to take them.

Same here, specifically python-requests-oauthlib and python-
resultsdb_api (I might take resultsdb_api sooner as it's kinda in our
wheelhouse). Another one that somebody should definitely take is
libcomps (everything breaks if that goes away).

There are several chains through qemu which show up in a lot of my
packages:

qemu -> ceph -> openssh -> libfido2 -> libcbor (unmaintained)
qemu -> brltty -> pkgconf -> atf (unmaintained)
qemu -> brltty -> linuxdoc-tools (unmaintained)
qemu -> systemtap -> crash (unmaintained)
qemu -> glusterfs -> pcs -> fence-agents (unmaintained)
qemu -> glusterfs -> pcs -> rubygem-sinatra -> rubygem-rdiscount (unmaintained)
qemu -> nvml (unmaintained)

so that's libcbor , atf , linuxdoc-tools , crash , fence-agents ,
rubygem-rdiscount and nvml that all need picking up or else qemu is
eventually in danger...
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Mark Reynolds]

On 11/28/22 1:20 PM, Mattia Verga via devel wrote:

Il 28/11/22 18:36, Nick Bebout ha scritto:

I've removed a lot of ACLs.  See attached log file.



Thanks Nick.

From your output I made a list of the orphaned packages which I think 
it's a bit more readable:


- container/cassandra
- container/php
- modules/389-ds


389-ds would be mine now.

Thanks,
Mark


- modules/timescaledb
- rpms/5minute
- rpms/CBFlib
- rpms/CFR
- rpms/CheMPS2
- rpms/NetworkManager-l2tp
- rpms/PolicyKit-olpc
- rpms/RdRand
- rpms/SFML
- rpms/ServiceReport
- rpms/abiword
- rpms/aboot
- rpms/abrt-java-connector
- rpms/activemq-cpp
- rpms/adwaita-qt
- rpms/aiksaurus
- rpms/airspyhf-1.6.8-1
- rpms/albatross
- rpms/alef-fonts
- rpms/alleyoop
- rpms/alure
- rpms/amor
- rpms/anki
- rpms/anyremote
- rpms/asio
- rpms/asn1c
- rpms/atf
- rpms/autotest-framework
- rpms/axis
- rpms/backup-manager
- rpms/baobab
- rpms/bbkeys
- rpms/bc
- rpms/bdsync
- rpms/bharati-m17n
- rpms/bibtex2html
- rpms/biosdevname
- rpms/blackbox
- rpms/bluebird
- rpms/bonnie++
- rpms/brainfuck
- rpms/brotli
- rpms/buildbot
- rpms/cairo-clock
- rpms/cave9
- rpms/cciss_vol_status
- rpms/celestia
- rpms/chisholm-to-be-continued-fonts
- rpms/clc
- rpms/clipper
- rpms/cmockery2
- rpms/code-editor
- rpms/compton
- rpms/converseen
- rpms/crash
- rpms/csslint
- rpms/ctan-cm-lgc-fonts
- rpms/ctan-kerkis-fonts
- rpms/cups-bjnp
- rpms/curlpp
- rpms/davix
- rpms/debconf
- rpms/debhelper
- rpms/deepin-account-faces
- rpms/deepin-api
- rpms/deepin-calculator
- rpms/deepin-control-center
- rpms/deepin-daemon
- rpms/deepin-desktop-base
- rpms/deepin-desktop-schemas
- rpms/deepin-dock
- rpms/deepin-draw
- rpms/deepin-editor
- rpms/deepin-file-manager
- rpms/deepin-gettext-tools
- rpms/deepin-gir-generator
- rpms/deepin-gtk-theme
- rpms/deepin-icon-theme
- rpms/deepin-image-viewer
- rpms/deepin-launcher
- rpms/deepin-menu
- rpms/deepin-network-utils
- rpms/deepin-picker
- rpms/deepin-polkit-agent
- rpms/deepin-qml-widgets
- rpms/deepin-qt-dbus-factory
- rpms/deepin-qt5integration
- rpms/deepin-screenshot
- rpms/deepin-session-ui
- rpms/deepin-shortcut-viewer
- rpms/deepin-sound-theme
- rpms/deepin-system-monitor
- rpms/deepin-terminal
- rpms/deepin-topbar
- rpms/deepin-wallpapers
- rpms/dmz-cursor-themes
- rpms/docker-compose
- rpms/drupal7-addressfield
- rpms/drupal7-admin_menu
- rpms/drupal7-admin_theme
- rpms/drupal7-block_class
- rpms/dtkcore
- rpms/dtkwidget
- rpms/dtkwm
- rpms/dynafed
- rpms/ebook-tools
- rpms/enchant
- rpms/erlang-epgsql
- rpms/eureka
- rpms/evas-generic-loaders
- rpms/fastback
- rpms/fcitx
- rpms/fcitx-chewing
- rpms/fcitx-cloudpinyin
- rpms/fcitx-configtool
- rpms/fcitx-fbterm
- rpms/fcitx-hangul
- rpms/fcitx-libpinyin
- rpms/fcitx-m17n
- rpms/fcitx-sunpinyin
- rpms/fcitx-table-extra
- rpms/fcitx-table-other
- rpms/fcitx-ui-light
- rpms/fcitx-unikey
- rpms/fedora-dockerfiles
- rpms/fence-agents
- rpms/flumotion
- rpms/fpc
- rpms/fros
- rpms/fusioninventory-agent
- rpms/fwsnort
- rpms/ganyremote
- rpms/gbrainy
- rpms/gdeploy
- rpms/genius
- rpms/geoclue2
- rpms/geocode-glib
- rpms/gfal2
- rpms/gfal2-python
- rpms/gfalFS
- rpms/gl-117
- rpms/glusterfs-selinux
- rpms/gnome-abrt
- rpms/gnome-activity-journal
- rpms/gnome-font-viewer
- rpms/gnome-initial-setup
- rpms/gnome-nds-thumbnailer
- rpms/gnome-passwordsafe
- rpms/gnome-photos
- rpms/gnome-search-tool
- rpms/gnome-settings-daemon
- rpms/gnome-shell-theme-selene
- rpms/golang-deepin-go-lib
- rpms/golang-github-alecthomas-assert
- rpms/golang-github-alecthomas-colour
- rpms/golang-github-alecthomas-repr
- rpms/golang-github-alecthomas-template
- rpms/golang-github-alecthomas-units
- rpms/golang-github-auth0-go-jwt-middleware
- rpms/golang-github-axgle-mahonia
- rpms/golang-github-cheekybits-is
- rpms/golang-github-codegangsta-negroni
- rpms/golang-github-cryptix-wav
- rpms/golang-github-disintegration-imaging
- rpms/golang-github-fogleman-gg
- rpms/golang-github-gocomply-scap
- rpms/golang-github-justinas-alice
- rpms/golang-github-linuxdeepin-dbus-factory
- rpms/golang-github-linuxdeepin-go-x11-client
- rpms/golang-github-lpabon-godbc
- rpms/golang-github-mitchellh-cli
- rpms/golang-github-msteinert-pam
- rpms/golang-github-nfnt-resize
- rpms/golang-github-pkg-browser
- rpms/golang-github-spaolacci-murmur3
- rpms/golie
- rpms/gperf
- rpms/grads
- rpms/gsm-ussd
- rpms/gtk-sharp3
- rpms/hatools
- rpms/heisenbug-kde-theme
- rpms/highcontrast-qt
- rpms/holland
- rpms/hunspell-kn
- rpms/ibus-table-others
- rpms/imwheel
- rpms/indefero
- rpms/intel-cmt-cat
- rpms/intel-ipsec-mb
- rpms/iperf3
- rpms/jama
- rpms/jargs
- rpms/java-mersenne-twister
- rpms/jcodings
- rpms/jdns
- rpms/jffi
- rpms/jgrapht
- rpms/jnr-constants
- rpms/jnr-ffi
- rpms/jnr-netdb
- rpms/jnr-posix
- rpms/jnr-x86asm
- rpms/js-web-socket-js
- rpms/kanyremote
- rpms/kcm-fcitx
- rpms/kcron
- rpms/kde-connect
- rpms/keylime
- rpms/kfaenza-icon-theme
- rpms/kfilefactory
- rpms/kompose
- rpms/kpcli
- rpms/krename
- rpms/krusader
- rpms/ksystemlog
- 

Re: Inactive packagers to be removed after the F37 release

[Kalev Lember]

On Mon, Nov 28, 2022 at 8:33 PM Kalev Lember  wrote:

> On Mon, Nov 28, 2022 at 7:20 PM Mattia Verga via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> - rpms/sysprof
>>
>
> I took sysprof as I've been de facto maintaining it for years.
>

... and also baobab, geocode-glib, gnome-font-viewer, gnome-initial-setup,
gnome-photos, gnome-settings-daemon.

-- 
Kalev

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kalev Lember]

On Mon, Nov 28, 2022 at 7:20 PM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> - rpms/sysprof
>

I took sysprof as I've been de facto maintaining it for years.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Artur Frenszek-Iwicki]

> - rpms/fpc
> - rpms/lazarus
I've been a co-admin on those, so I took 'em.

Several of the orphaned packages are dependencies of stuff I currently maintain.
I'll wait a week or two to see if anyone else wants to take them.

A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Jonathan Wright via devel]

I took a few packages.  I'm trying to also take bonnie++ but the take
request is returning a 500 error.

On Mon, Nov 28, 2022 at 12:35 PM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 28/11/22 19:20, Mattia Verga ha scritto:
> > From your output I made a list of the orphaned packages which I think
> > it's a bit more readable:
> >
> > ...
> > - rpms/celestia
> >
> Taken and added astro-sig as co-maintainer, I'll try to update it to the
> latest version.
> >
> > ...
> > - rpms/python-simplemediawiki.
> >
> Taken as well, as it is needed by Bodhi, until I manage to port it to
> python-pymediawiki.
>
> Mattia
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Mattia Verga via devel]

Il 28/11/22 19:20, Mattia Verga ha scritto:
> From your output I made a list of the orphaned packages which I think
> it's a bit more readable:
>
> ...
> - rpms/celestia
>
Taken and added astro-sig as co-maintainer, I'll try to update it to the
latest version.
>
> ...
> - rpms/python-simplemediawiki.
>
Taken as well, as it is needed by Bodhi, until I manage to port it to
python-pymediawiki.

Mattia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Mattia Verga via devel]

Il 28/11/22 18:36, Nick Bebout ha scritto:

> I've removed a lot of ACLs. See attached log file.

Thanks Nick.

From your output I made a list of the orphaned packages which I think it's a 
bit more readable:

- container/cassandra
- container/php
- modules/389-ds
- modules/timescaledb
- rpms/5minute
- rpms/CBFlib
- rpms/CFR
- rpms/CheMPS2
- rpms/NetworkManager-l2tp
- rpms/PolicyKit-olpc
- rpms/RdRand
- rpms/SFML
- rpms/ServiceReport
- rpms/abiword
- rpms/aboot
- rpms/abrt-java-connector
- rpms/activemq-cpp
- rpms/adwaita-qt
- rpms/aiksaurus
- rpms/airspyhf-1.6.8-1
- rpms/albatross
- rpms/alef-fonts
- rpms/alleyoop
- rpms/alure
- rpms/amor
- rpms/anki
- rpms/anyremote
- rpms/asio
- rpms/asn1c
- rpms/atf
- rpms/autotest-framework
- rpms/axis
- rpms/backup-manager
- rpms/baobab
- rpms/bbkeys
- rpms/bc
- rpms/bdsync
- rpms/bharati-m17n
- rpms/bibtex2html
- rpms/biosdevname
- rpms/blackbox
- rpms/bluebird
- rpms/bonnie++
- rpms/brainfuck
- rpms/brotli
- rpms/buildbot
- rpms/cairo-clock
- rpms/cave9
- rpms/cciss_vol_status
- rpms/celestia
- rpms/chisholm-to-be-continued-fonts
- rpms/clc
- rpms/clipper
- rpms/cmockery2
- rpms/code-editor
- rpms/compton
- rpms/converseen
- rpms/crash
- rpms/csslint
- rpms/ctan-cm-lgc-fonts
- rpms/ctan-kerkis-fonts
- rpms/cups-bjnp
- rpms/curlpp
- rpms/davix
- rpms/debconf
- rpms/debhelper
- rpms/deepin-account-faces
- rpms/deepin-api
- rpms/deepin-calculator
- rpms/deepin-control-center
- rpms/deepin-daemon
- rpms/deepin-desktop-base
- rpms/deepin-desktop-schemas
- rpms/deepin-dock
- rpms/deepin-draw
- rpms/deepin-editor
- rpms/deepin-file-manager
- rpms/deepin-gettext-tools
- rpms/deepin-gir-generator
- rpms/deepin-gtk-theme
- rpms/deepin-icon-theme
- rpms/deepin-image-viewer
- rpms/deepin-launcher
- rpms/deepin-menu
- rpms/deepin-network-utils
- rpms/deepin-picker
- rpms/deepin-polkit-agent
- rpms/deepin-qml-widgets
- rpms/deepin-qt-dbus-factory
- rpms/deepin-qt5integration
- rpms/deepin-screenshot
- rpms/deepin-session-ui
- rpms/deepin-shortcut-viewer
- rpms/deepin-sound-theme
- rpms/deepin-system-monitor
- rpms/deepin-terminal
- rpms/deepin-topbar
- rpms/deepin-wallpapers
- rpms/dmz-cursor-themes
- rpms/docker-compose
- rpms/drupal7-addressfield
- rpms/drupal7-admin_menu
- rpms/drupal7-admin_theme
- rpms/drupal7-block_class
- rpms/dtkcore
- rpms/dtkwidget
- rpms/dtkwm
- rpms/dynafed
- rpms/ebook-tools
- rpms/enchant
- rpms/erlang-epgsql
- rpms/eureka
- rpms/evas-generic-loaders
- rpms/fastback
- rpms/fcitx
- rpms/fcitx-chewing
- rpms/fcitx-cloudpinyin
- rpms/fcitx-configtool
- rpms/fcitx-fbterm
- rpms/fcitx-hangul
- rpms/fcitx-libpinyin
- rpms/fcitx-m17n
- rpms/fcitx-sunpinyin
- rpms/fcitx-table-extra
- rpms/fcitx-table-other
- rpms/fcitx-ui-light
- rpms/fcitx-unikey
- rpms/fedora-dockerfiles
- rpms/fence-agents
- rpms/flumotion
- rpms/fpc
- rpms/fros
- rpms/fusioninventory-agent
- rpms/fwsnort
- rpms/ganyremote
- rpms/gbrainy
- rpms/gdeploy
- rpms/genius
- rpms/geoclue2
- rpms/geocode-glib
- rpms/gfal2
- rpms/gfal2-python
- rpms/gfalFS
- rpms/gl-117
- rpms/glusterfs-selinux
- rpms/gnome-abrt
- rpms/gnome-activity-journal
- rpms/gnome-font-viewer
- rpms/gnome-initial-setup
- rpms/gnome-nds-thumbnailer
- rpms/gnome-passwordsafe
- rpms/gnome-photos
- rpms/gnome-search-tool
- rpms/gnome-settings-daemon
- rpms/gnome-shell-theme-selene
- rpms/golang-deepin-go-lib
- rpms/golang-github-alecthomas-assert
- rpms/golang-github-alecthomas-colour
- rpms/golang-github-alecthomas-repr
- rpms/golang-github-alecthomas-template
- rpms/golang-github-alecthomas-units
- rpms/golang-github-auth0-go-jwt-middleware
- rpms/golang-github-axgle-mahonia
- rpms/golang-github-cheekybits-is
- rpms/golang-github-codegangsta-negroni
- rpms/golang-github-cryptix-wav
- rpms/golang-github-disintegration-imaging
- rpms/golang-github-fogleman-gg
- rpms/golang-github-gocomply-scap
- rpms/golang-github-justinas-alice
- rpms/golang-github-linuxdeepin-dbus-factory
- rpms/golang-github-linuxdeepin-go-x11-client
- rpms/golang-github-lpabon-godbc
- rpms/golang-github-mitchellh-cli
- rpms/golang-github-msteinert-pam
- rpms/golang-github-nfnt-resize
- rpms/golang-github-pkg-browser
- rpms/golang-github-spaolacci-murmur3
- rpms/golie
- rpms/gperf
- rpms/grads
- rpms/gsm-ussd
- rpms/gtk-sharp3
- rpms/hatools
- rpms/heisenbug-kde-theme
- rpms/highcontrast-qt
- rpms/holland
- rpms/hunspell-kn
- rpms/ibus-table-others
- rpms/imwheel
- rpms/indefero
- rpms/intel-cmt-cat
- rpms/intel-ipsec-mb
- rpms/iperf3
- rpms/jama
- rpms/jargs
- rpms/java-mersenne-twister
- rpms/jcodings
- rpms/jdns
- rpms/jffi
- rpms/jgrapht
- rpms/jnr-constants
- rpms/jnr-ffi
- rpms/jnr-netdb
- rpms/jnr-posix
- rpms/jnr-x86asm
- rpms/js-web-socket-js
- rpms/kanyremote
- rpms/kcm-fcitx
- rpms/kcron
- rpms/kde-connect
- rpms/keylime
- rpms/kfaenza-icon-theme
- rpms/kfilefactory
- rpms/kompose
- rpms/kpcli
- rpms/krename
- rpms/krusader
- rpms/ksystemlog
- rpms/kteatime
- rpms/ladspa
- rpms/lazarus
- rpms/libannodex
- rpms/libbsr
- rpms/libcaca
- 

Re: Inactive packagers to be removed after the F37 release

[Nick Bebout]

I have removed these accounts from the packager group, and am currently
running a script to remove their ACLs.  I will post on devel list when it
is complete (along with the packages that are orphaned)

On Sat, Nov 26, 2022 at 2:05 AM Mattia Verga via devel <
devel@lists.fedoraproject.org> wrote:

> Il 24/11/22 09:38, Vít Ondruch ha scritto:
> > @Ben isn't it the time to finish this round?
> >
> >
> > Vít
> >
> >
> It's being worked on in
> https://pagure.io/fedora-infrastructure/issue/11002
>
> Mattia
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Mattia Verga via devel]

Il 24/11/22 09:38, Vít Ondruch ha scritto:
> @Ben isn't it the time to finish this round?
>
>
> Vít
>
>
It's being worked on in https://pagure.io/fedora-infrastructure/issue/11002

Mattia

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

@Ben isn't it the time to finish this round?


Vít


Dne 18. 08. 22 v 23:28 Ben Cotton napsal(a):

Hello everyone!

I just completed the first run of FESCo's newly approved Inactive
Packager Policy[1]. Packagers that have been identified as inactive
have a ticket in the find-inactive-packagers repo[2]. One week after
the F37 final release, packagers who remain inactive will be removed
from the packager group. (Note that pagure.io is one of the systems
checked for activity, so commenting on your ticket that you're still
around will prevent you from showing up in the second round.)

Since this is the first time we've done something like this, it could
be a little rough. I appreciate your patience and understanding. If
you have suggestions for improvement, look for the open feature
issues[3] and file an issue in the find-inactive-packagers repo[4] if
it's not there already.

For the curious, here are the stats from today's run:

2550 users checked
913 of those had no activity on src.fedoraproject.org or pagure.io
835 of those had no activity in Bodhi
812 of those had no activity on the mailing lists
606 of those (~24% of packagers) had no activity in Bugzilla.

The script took a little under three hours to run.

[1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
[2] 
https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager=Open
[3] https://pagure.io/find-inactive-packagers/issues?tags=feature
[4] https://pagure.io/find-inactive-packagers/new_issue



OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

Hi,

On to, 15 syys 2022, Kevin Fenzi wrote:

> CentOS folks still use certs for their koji:
> https://wiki.centos.org/Authentication#TLS_certificate
> (and thats using the same account system/ipa servers as fedora).
>
> > I hope we can plan to work together on this improvement again, similar
> > how we did with the initial rewrite of Fedora Accounts on top of
> > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > perhaps CPA team could consider scheduling this effort as part of the
> > initiatives.
>
> Yeah, I would like that. Perhaps we could setup a meeting soon and
> dicuss plans? I'm open to video meeting, but we could also do IRC to
> keep things more open...

I am open to it too, may be in couple weeks or so, to allow interested
parties to prepare.


Sure. Can you schedule something when you are ready/available and we can
go from there.


It took me more than couple weeks...

I have been working on an article to describe what we are doing in
FreeIPA and SSSD world with authentication against various identity
providers and how that could help the Fedora Infrastructure.

Long story short, there are now two articles:

Part 1, where I am talking about Fedora infrastructure aspects: 
https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra/


Part 2, where FreeIPA-specific improvements and details discussed:
https://vda.li/en/posts/2022/10/28/FreeIPA-Authentication-Improvements-and-Fedora-Infra-2/



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Mon, Sep 19, 2022 at 05:58:36PM +0200, Vít Ondruch wrote:
> 
> Dne 16. 09. 22 v 19:03 Kevin Fenzi napsal(a):
> > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> > > Isn't peer review much better and easier solution over all? We could also
> > > require signed commits I guess.
> > I think it would slow things down quite a lot to require peer review of
> > every commit.
> 
> 
> This proposal was based mainly upon the conversation, where nothing what was
> proposed was secure enough. Every proposal was shot down having some
> possible holes. While peer review might be slow and it is certainly not
> bullet proof, I don't think we can do any better.

Well, the problem is 'secure enough'. Security is not a checkbox. 
You can't ever say "ok, we are secure". Security is a process. What
things you do are based on what possible solutions you have and what
possible attacks you have and the tradeoffs you have to make to
implement things. 

I don't personally think right now the tradeoffs are worth requiring
review for every change. I fear it would result in a lot of "hey can you
+1 my change" and people just clicking reviewed without reviewing. Bad
actors would just need to find another person to approve their change
without much review. Of course a lot of people would review and perhaps
it would improve overall quality.

Long ago, when number of changes was small... I used to actually read
all of them and comment when I found something concerning. I've not been
able to do that in many years tho... In the past 30 days there have been
41080 changes to spec files. That is a ton.

> And BTW, when I talk about peer review, I think that also ex-post peer
> review is valuable. E.g. if I contribute to some package, I'll look at every
> commit notification and check the changes. If I see something concerning,
> I'll try to address it. Better late then never.

Absoluetely.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 16. 09. 22 v 19:03 Kevin Fenzi napsal(a):

On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:

Isn't peer review much better and easier solution over all? We could also
require signed commits I guess.

I think it would slow things down quite a lot to require peer review of
every commit.



This proposal was based mainly upon the conversation, where nothing what 
was proposed was secure enough. Every proposal was shot down having some 
possible holes. While peer review might be slow and it is certainly not 
bullet proof, I don't think we can do any better.


And BTW, when I talk about peer review, I think that also ex-post peer 
review is valuable. E.g. if I contribute to some package, I'll look at 
every commit notification and check the changes. If I see something 
concerning, I'll try to address it. Better late then never.



Vít




I'd personally like to avoid anything where we need to support gpg.
It's a mess and I think it would waste a lot of cycles explaining how to
use it or help people get setup. ;( If there's some easier/more clear
way to sign things that could be a option tho.

kevin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/19/22 04:52, Petr Pisar wrote:
> V Fri, Sep 16, 2022 at 01:56:03PM -0400, Todd Zullinger napsal(a):
>> Kevin Fenzi wrote:
>>> On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
 Isn't peer review much better and easier solution over all? We could also
 require signed commits I guess.
>>>
>>> I think it would slow things down quite a lot to require peer review of
>>> every commit. 
>>>
>>> I'd personally like to avoid anything where we need to support gpg.
>>> It's a mess and I think it would waste a lot of cycles explaining how to
>>> use it or help people get setup. ;( If there's some easier/more clear
>>> way to sign things that could be a option tho.
>>
>> Since git-2.34 (released in November of last year), ssh may
>> be used for signing commits and/or pushes.  That's likely a
>> bit simpler than gpg.
>>
> Is administrating SSH keys any easier (for a packager and for Fedora
> infrastructure) than PGP keys?

Yes, it is.  ssh-keygen -Y is much much simpler to use than gpg.
Verifying SSH signatures does not expose Fedora servers to DoS
attacks the way verifying PGP signatures would.  And the same
key can be used for both SSH and for signing, without creating
security risks.  Furthermore, OpenSSH supports using any FIDO2
token for key storage, not just more expensive PGP-capable
tokens.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Fri, Sep 16, 2022 at 01:56:03PM -0400, Todd Zullinger napsal(a):
> Kevin Fenzi wrote:
> > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> >> Isn't peer review much better and easier solution over all? We could also
> >> require signed commits I guess.
> > 
> > I think it would slow things down quite a lot to require peer review of
> > every commit. 
> > 
> > I'd personally like to avoid anything where we need to support gpg.
> > It's a mess and I think it would waste a lot of cycles explaining how to
> > use it or help people get setup. ;( If there's some easier/more clear
> > way to sign things that could be a option tho.
> 
> Since git-2.34 (released in November of last year), ssh may
> be used for signing commits and/or pushes.  That's likely a
> bit simpler than gpg.
> 
Is administrating SSH keys any easier (for a packager and for Fedora
infrastructure) than PGP keys?

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Fri, Sep 16, 2022 at 05:30:13PM +, Tommy Nguyen napsal(a):
> With that being said, if a GPG key would be compromised, wouldn't it
> result in an error when trying to update the package? An end user would
> then report the bug, someone would see that the key does not match the
> signature in the gpg-distribution package, signalling that it's
> compromised.

Compromised GPG key means something else. It means that you have a valid
signature for a package made with a genuine Fedora packager's key. But not
made by the Fedora packager. You won't recognize a compromised key by checking
the signatures.

You probably wanted to write a compromised dist-git account. In that case the
GPG signature would help.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Todd Zullinger]

Kevin Fenzi wrote:
> On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
>> Isn't peer review much better and easier solution over all? We could also
>> require signed commits I guess.
> 
> I think it would slow things down quite a lot to require peer review of
> every commit. 
> 
> I'd personally like to avoid anything where we need to support gpg.
> It's a mess and I think it would waste a lot of cycles explaining how to
> use it or help people get setup. ;( If there's some easier/more clear
> way to sign things that could be a option tho.

Since git-2.34 (released in November of last year), ssh may
be used for signing commits and/or pushes.  That's likely a
bit simpler than gpg.

On the other hand, if it's cached by ssh-agent and/or uses
the same key used to connect to dist-git, it might not add
as much to the security as we might want.

But it may be an option, in case it spurs anyone to come up
with a change which improves security and doesn't add too
much additional burden.

You mentioned ecdsa-sk / ed25519-sk FIDO authenticator
algorithms earlier.  Git ssh-signed commit/push might be
useful if/when other parts of our  infrastructure can make
use of those key types.

-- 
Todd


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Fri, 2022-09-16 at 17:16 +, Dan Čermák wrote:
> Hi,
> 
> On September 16, 2022 5:03:03 PM UTC, Kevin Fenzi 
> wrote:
> > On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> > > Isn't peer review much better and easier solution over all? We
> > > could also
> > > require signed commits I guess.
> > 
> > I think it would slow things down quite a lot to require peer
> > review of
> > every commit. 
> 
> It would a bit, but it is doable. openSUSE tumbleweed works like
> that: every commit that is sent into the rolling distro is reviewed
> by the release managers. It adds some overhead and it would most
> certainly require dedicated reviewers and additional tooling.
> 
> > I'd personally like to avoid anything where we need to support gpg.
> > It's a mess and I think it would waste a lot of cycles explaining
> > how to
> > use it or help people get setup. ;( If there's some easier/more
> > clear
> > way to sign things that could be a option tho.
> > 
> > kevin

I don't think it would help in this particular case anyway. Downstream
avoids malicious behavior on upstream by downloading a specific tar
ball, verifying its hash, then building it on Fedora's infrastructure.
That means any malicious commit will be caught by packagers.

Now let's imagine the same attack scenario for downstream. They would
somehow need commit privileges then to forge a commit. But I think in
this scenario, they would need commit privileges, but not access to the
gpg key right? So you would see an "unverified" commit. But all this
signals to us is that the packager's account is compromised. Which
there are other ways of determining that and there's other damage the
attacker can do if they somehow compromised the account.

Verifying every commit does not seem scalable either. Someone mentioned
that there's 20k~ packages in the base repos. The current approach
involves mostly automation, QA and validation testing to catch any
bugs. How would every commit be reviewed? It makes sense on the scale
of something like the Linux kernel where you have a hierarchy (Linus,
his release managers, project owners, then people below that). For
Fedora, it would add way too much bureaucracy and overhead and probably
not even give that much benefit.

With that being said, if a GPG key would be compromised, wouldn't it
result in an error when trying to update the package? An end user would
then report the bug, someone would see that the key does not match the
signature in the gpg-distribution package, signalling that it's
compromised.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Dan Čermák]

Hi,

On September 16, 2022 5:03:03 PM UTC, Kevin Fenzi  wrote:
>On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
>> Isn't peer review much better and easier solution over all? We could also
>> require signed commits I guess.
>
>I think it would slow things down quite a lot to require peer review of
>every commit. 

It would a bit, but it is doable. openSUSE tumbleweed works like that: every 
commit that is sent into the rolling distro is reviewed by the release 
managers. It adds some overhead and it would most certainly require dedicated 
reviewers and additional tooling.

>I'd personally like to avoid anything where we need to support gpg.
>It's a mess and I think it would waste a lot of cycles explaining how to
>use it or help people get setup. ;( If there's some easier/more clear
>way to sign things that could be a option tho.
>
>kevin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Fri, Sep 16, 2022 at 10:03:35AM +0200, Vít Ondruch wrote:
> Isn't peer review much better and easier solution over all? We could also
> require signed commits I guess.

I think it would slow things down quite a lot to require peer review of
every commit. 

I'd personally like to avoid anything where we need to support gpg.
It's a mess and I think it would waste a lot of cycles explaining how to
use it or help people get setup. ;( If there's some easier/more clear
way to sign things that could be a option tho.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Fri, Sep 16, 2022 at 10:29:17AM +0300, Alexander Bokovoy wrote:
> 
> One thing I want to get properly implemented in SSSD in upcoming FIDO2
> support is to allow admins to filter out certain types of public SSH
> keys associated with the user account. E.g. get a way for administrator
> to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk,
> ed25519-sk) allowed for these users' and let SSSD's
> sss_ssh_authorized_keys to filter all other types. Then your git server
> could be able to deny non-FIDO2 SSH keys on per-user base.

That would be cool. 

Even better IMHO would be support for ssh certs. 
ie, auth with your FIDO2 key/otp and you get a ssh cert thats has a time
limit / other restrictions for just pushing git commits, etc.

> FreeIPA Kerberos already gives you this feature for various
> authentication methods[1] but it is not integrated in OpenSSH's GSSAPI
> support.
> 
> [1] 
> https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html
> 
> > > these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
> > > (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
> > > a smartcard is typically your government-issued ID in many countries.
> > > 
> > > Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
> > > enough to a lower boundary.
> > 
> > Yeah, it will still be hard to require 100% of packagers, but it might
> > be doable.
> 
> Solving this is a social problem. I'd like to remove technical
> roadblocks so that we can better focus on the solutions to social
> problems. Right now we aren't there on both sides.

Agreed.

...snip...

> Sure. I guess we can aim last week of October. I'll write up a call for
> participation next week.

Thanks.
 
> > > > > Do we have any statistics of how we stand now that Fedora Accounts is
> > > > > deployed for more than a year and people were enabled to use 2FA 
> > > > > tokens
> > > > > through it?
> > > >
> > > > I could try and gather some. What stats would be helpfull?
> > > 
> > > A particular argument by smooge and others was arount 'passwords or
> > > tokens being lost frequently'. I'd like to see how widespread is this
> > > problem. Can we collect stats on amount of requests to reset passwords,
> > > reset tokens, etc. for a period of a year or so?
> > 
> > We currently have 1560 tokens enrolled.
> > (Of course some users have more than one, but most seem to have one)
> > 
> > In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to
> > reset otp. Some of these were people who were confused and didn't actually
> > even have a otp enabled, but it's hard to count those without going
> > through each request.
> > 
> > So, it's less than 5% a year it seems like, or a request every 4days if
> > they were evenly spaced.
> 
> Thank you. This is actually better than I expected to see. Improving
> technical measures and UX should help but there always will be something
> that is harder to deal with, anyway.

I'll also note that I think many more of them came toward the first part
of that time period. We made some changes to the interface that helped a
good deal. At first we had a mailto: link and got a bunch of blank
emails (bots just following the link? confused users?)
https://github.com/fedora-infra/noggin/issues/678

So, it might be interesting to see how things look after that change
landed.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Aside: Re: Inactive packagers to be removed after the F37 release

[stan via devel]

On Thu, 15 Sep 2022 11:57:53 -0700
Adam Williamson  wrote:

> We have "critical path" groups for lots of desktops, including ones
> that aren't release-blocking: deepin, lxde, lxqt, and xfce. The logic
> here is approximately: things that are critical to those desktops are
> indeed critical to users of those desktops, and don't affect anybody
> else. So it makes sense to put them on the "critical path", because to
> the relatively small subset of users who *do* use those desktops, the
> updates really *are* critical, and it doesn't hurt users of any other
> desktop for them to be held up.

This sounds a lot more like critical set or critical graph (as in
node-edge) than critical path.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Jiri Vanek]

Just very minor contribution to alrready very complex trhead.

- to remove packager status if they are not using it, is just wrong. OpenJDK was using it far years and  it really did not proved itself. Now OpenJDK have policy, that once you earn any status, you remain with it. The downgrade or no longer 
propagated status (eg form project to project) was super confussing and made more issues then it solved. Now it is much better.


- to remove proven packager status, if they are nto using proven packagers powers, is similarly wrong. Well, if there is email with deadlnie.. then maybe... As for my case - I'm not using my proven packager powers, but once per two years, 
I'm bumping system JDK. And n that moment I'm using my proven packager skill heavily.  So hard timeout, would again do just confussion (like negotiating proven packager status again 5 minutes before dealines)


I belive all liek thsi was already said
  Thanx all for making fedora just better and better!

J.

On 9/3/22 22:04, Kevin Fenzi wrote:

On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote:


So, I have a probably-controversial idea for a follow-up on this.

Even after this sweep, we have 141 proven packagers. That's a lot of
people who can build almost anything in Fedora.

It should be possible to check whether a provenpackager has built any
package they don't have direct commit rights to in the last X months.

Should we construct that search, run it, and propose removing
provenpackager status from folks who aren't using it, to cut down that
set?


That policy was setup before this one for packagers. ;)

https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

kevin


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Isn't peer review much better and easier solution over all? We could 
also require signed commits I guess.



Vít


Dne 15. 09. 22 v 20:36 Gary Buhrmaster napsal(a):

On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi  wrote:

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:

Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?

Perhaps any packager who has a package in one of the critical path lists?
That number (of package(r)s) may be a bit large, though, for an initial cut
(as I recall, the total number of critical path packages is around 1000
in rawhide, although I have no idea how many packagers that is).


As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement.

Especially if one would like that any enforcement be semi-automatic
rather than one more manual step when adding people to groups.


Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might
be doable.

And, as has been previously pointed out, it is also possible
(although depending on the implementation not as secure) to
use other pkcs11 backends, including software implementations.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On to, 15 syys 2022, Kevin Fenzi wrote:

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:


Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?


Well, as others noted in this thread, any packager has a lot of power.
They can add a weak dep on something everyone has installed and pull
their package in. Of course they likely only get to do that once.


There is probably a value in defining what functions critical to have
strongly authenticated and identified to the distribution at large. For
example, right now even 2FA OTP requirement is not mandatory for certain
package groups.


As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement.


It is on my radar.


Additionally, right now, packagers commit with ssh keys or oidc tokens,
in order for a 2fa setup to be effective, we would need to switch that
to kerberos or the like.


One thing I want to get properly implemented in SSSD in upcoming FIDO2
support is to allow admins to filter out certain types of public SSH
keys associated with the user account. E.g. get a way for administrator
to say 'only FIDO2 keys and their OpenSSH equivalents (ecdsa-sk,
ed25519-sk) allowed for these users' and let SSSD's
sss_ssh_authorized_keys to filter all other types. Then your git server
could be able to deny non-FIDO2 SSH keys on per-user base.

FreeIPA Kerberos already gives you this feature for various
authentication methods[1] but it is not integrated in OpenSSH's GSSAPI
support.

[1] 
https://freeipa.readthedocs.io/en/latest/workshop/11-kerberos-ticket-policy.html


these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
(Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
a smartcard is typically your government-issued ID in many countries.

Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
enough to a lower boundary.


Yeah, it will still be hard to require 100% of packagers, but it might
be doable.


Solving this is a social problem. I'd like to remove technical
roadblocks so that we can better focus on the solutions to social
problems. Right now we aren't there on both sides.


Anyway, using a soft-based smartcard e.g. using NSS database stored on a
usb flash drive and accessible via PKCS11 could also be an option. The
problem here is to attest to a server side it is protected by the client
but this is a common problem to all different methods. Even storing a
key-pair on your hard drive would work with Kerberos PKINIT without any
problem.

> CentOS folks still use certs for their koji:
> https://wiki.centos.org/Authentication#TLS_certificate
> (and thats using the same account system/ipa servers as fedora).
>
> > I hope we can plan to work together on this improvement again, similar
> > how we did with the initial rewrite of Fedora Accounts on top of
> > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > perhaps CPA team could consider scheduling this effort as part of the
> > initiatives.
>
> Yeah, I would like that. Perhaps we could setup a meeting soon and
> dicuss plans? I'm open to video meeting, but we could also do IRC to
> keep things more open...

I am open to it too, may be in couple weeks or so, to allow interested
parties to prepare.


Sure. Can you schedule something when you are ready/available and we can
go from there.


Sure. I guess we can aim last week of October. I'll write up a call for
participation next week.


> > Do we have any statistics of how we stand now that Fedora Accounts is
> > deployed for more than a year and people were enabled to use 2FA tokens
> > through it?
>
> I could try and gather some. What stats would be helpfull?

A particular argument by smooge and others was arount 'passwords or
tokens being lost frequently'. I'd like to see how widespread is this
problem. Can we collect stats on amount of requests to reset passwords,
reset tokens, etc. for a period of a year or so?


We currently have 1560 tokens enrolled.
(Of course some users have more than one, but most seem to have one)

In the 1 year period from 2021-07-01 to 2022-07-01 we had 87 requests to
reset otp. Some of these were people who were confused and didn't actually
even have a otp enabled, but it's hard to count those without going
through each request.

So, it's less than 5% a year it seems like, or a request every 4days if
they were evenly spaced.


Thank you. This is actually better than I expected to see. Improving
technical measures and UX should help but there always will be something
that is harder to deal with, anyway.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of 

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Thu, Sep 15, 2022 at 04:34:08PM -0400, Demi Marie Obenour wrote:
> On 9/15/22 13:55, Kevin Fenzi wrote:
> > On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> >>
> >> Proven packagers seem to be a fair category to address. Also packagers
> >> responsible for security-related bits of the distribution. Compilers?
> > 
> > Well, as others noted in this thread, any packager has a lot of power. 
> > They can add a weak dep on something everyone has installed and pull
> > their package in. Of course they likely only get to do that once. 
> > 
> >> There is probably a value in defining what functions critical to have
> >> strongly authenticated and identified to the distribution at large. For
> >> example, right now even 2FA OTP requirement is not mandatory for certain
> >> package groups.
> > 
> > As far as I know, it's not possible to enforce otp per group is it?
> > That would be a nice enhancement. 
> > 
> > Additionally, right now, packagers commit with ssh keys or oidc tokens,
> > in order for a 2fa setup to be effective, we would need to switch that
> > to kerberos or the like.
> 
> SSH keys are fine.

Sure, but unless you are using ecdsa-sk or ed25519-sk keys, they aren't
2factor enabled. Your account could be using OTP, but if someone gets
your ssh private key they can commit as you. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Thu, Sep 15, 2022 at 11:54:13AM -0700, Adam Williamson wrote:
> On Thu, 2022-09-15 at 10:55 -0700, Kevin Fenzi wrote:
> > On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> > > 
> > > Proven packagers seem to be a fair category to address. Also packagers
> > > responsible for security-related bits of the distribution. Compilers?
> > 
> > Well, as others noted in this thread, any packager has a lot of power. 
> > They can add a weak dep on something everyone has installed and pull
> > their package in. Of course they likely only get to do that once. 
> 
> I kinda feel like we really ought to just stick a check for this
> *somewhere*. An alert should pop up somewhere any time anyone adds a
> Supplements: line to *anything*. It's a sufficiently odd thing to do
> that it shouldn't happen very often, I think...
> 
> I suspect in the past the answer to this would be "Patrick probably
> does it already". Did we find a Patrick 2.0 yet? :D

Ha. no. 

There is a hook we have that notifies people when someone adds an
exclude/exclusivearch. We could make another one that checks for
Suggests I suppose. 

They could just add Requires tho, or add something that makes the auto
dep generating scripts add a requires or suggests. 

So, perhaps a CI check would be better, to check the actual produced
binary package.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/15/22 13:55, Kevin Fenzi wrote:
> On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
>>
>> Proven packagers seem to be a fair category to address. Also packagers
>> responsible for security-related bits of the distribution. Compilers?
> 
> Well, as others noted in this thread, any packager has a lot of power. 
> They can add a weak dep on something everyone has installed and pull
> their package in. Of course they likely only get to do that once. 
> 
>> There is probably a value in defining what functions critical to have
>> strongly authenticated and identified to the distribution at large. For
>> example, right now even 2FA OTP requirement is not mandatory for certain
>> package groups.
> 
> As far as I know, it's not possible to enforce otp per group is it?
> That would be a nice enhancement. 
> 
> Additionally, right now, packagers commit with ssh keys or oidc tokens,
> in order for a 2fa setup to be effective, we would need to switch that
> to kerberos or the like.

SSH keys are fine.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Gary Buhrmaster]

On Thu, Sep 15, 2022 at 6:58 PM Adam Williamson
 wrote:

> There's a kind of "surprising" property of the critical path list too -
> it contains some things you might not expect.

I was (initially) thinking of the critical-path-base list,
but you are right that the critical path is in the eyes of
the beholder.

> Which I still would like to work on in some of my
> copious spare time.

If you find a source of copious spare time, please
do pass it along.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Thu, 2022-09-15 at 18:36 +, Gary Buhrmaster wrote:
> On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi  wrote:
> > 
> > On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> > > 
> > > Proven packagers seem to be a fair category to address. Also packagers
> > > responsible for security-related bits of the distribution. Compilers?
> 
> Perhaps any packager who has a package in one of the critical path lists?
> That number (of package(r)s) may be a bit large, though, for an initial cut
> (as I recall, the total number of critical path packages is around 1000
> in rawhide, although I have no idea how many packagers that is).

There's a kind of "surprising" property of the critical path list too -
it contains some things you might not expect.

We have "critical path" groups for lots of desktops, including ones
that aren't release-blocking: deepin, lxde, lxqt, and xfce. The logic
here is approximately: things that are critical to those desktops are
indeed critical to users of those desktops, and don't affect anybody
else. So it makes sense to put them on the "critical path", because to
the relatively small subset of users who *do* use those desktops, the
updates really *are* critical, and it doesn't hurt users of any other
desktop for them to be held up.

Still, we might not want to enforce 2FA requirements for those
packages.

This would be another good reason to make the critpath definition more
sophisticated - keeping track of which critpath groups a package is
part of. Which I still would like to work on in some of my copious
spare time...sigh.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Thu, 2022-09-15 at 10:55 -0700, Kevin Fenzi wrote:
> On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> > 
> > Proven packagers seem to be a fair category to address. Also packagers
> > responsible for security-related bits of the distribution. Compilers?
> 
> Well, as others noted in this thread, any packager has a lot of power. 
> They can add a weak dep on something everyone has installed and pull
> their package in. Of course they likely only get to do that once. 

I kinda feel like we really ought to just stick a check for this
*somewhere*. An alert should pop up somewhere any time anyone adds a
Supplements: line to *anything*. It's a sufficiently odd thing to do
that it shouldn't happen very often, I think...

I suspect in the past the answer to this would be "Patrick probably
does it already". Did we find a Patrick 2.0 yet? :D
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Gary Buhrmaster]

On Thu, Sep 15, 2022 at 5:55 PM Kevin Fenzi  wrote:
>
> On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> >
> > Proven packagers seem to be a fair category to address. Also packagers
> > responsible for security-related bits of the distribution. Compilers?

Perhaps any packager who has a package in one of the critical path lists?
That number (of package(r)s) may be a bit large, though, for an initial cut
(as I recall, the total number of critical path packages is around 1000
in rawhide, although I have no idea how many packagers that is).

> As far as I know, it's not possible to enforce otp per group is it?
> That would be a nice enhancement.

Especially if one would like that any enforcement be semi-automatic
rather than one more manual step when adding people to groups.

> > Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
> > enough to a lower boundary.
>
> Yeah, it will still be hard to require 100% of packagers, but it might
> be doable.

And, as has been previously pointed out, it is also possible
(although depending on the implementation not as secure) to
use other pkcs11 backends, including software implementations.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Przemek Klosowski via devel]

On 9/14/22 03:51, Vitaly Zaitsev via devel wrote:

On 13/09/2022 23:50, Demi Marie Obenour wrote:

Another option is a TPM-based authenticator.  Would this be acceptable?


No. TPM 2.0 chip is a *proprietary* black box. Some of them have known 
critical security vulnerabilities[1]. 


OK, but so is every onther secure processor (yubikeys, finians, etc). At 
least TPM2 is ubiquitous, and watched/tested widely, and being improved 
as a result. The vulnerability you refer to was due to not encrypting 
LPC traffic between the motherboard and the TPM chip, which was 
apparently due to the implementation being lazy rather than a TPM 
deficiency. Traffic encryption is a standard protocol feature, and is 
increasingly being used.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Thu, Sep 15, 2022 at 09:26:36AM +0300, Alexander Bokovoy wrote:
> 
> Proven packagers seem to be a fair category to address. Also packagers
> responsible for security-related bits of the distribution. Compilers?

Well, as others noted in this thread, any packager has a lot of power. 
They can add a weak dep on something everyone has installed and pull
their package in. Of course they likely only get to do that once. 

> There is probably a value in defining what functions critical to have
> strongly authenticated and identified to the distribution at large. For
> example, right now even 2FA OTP requirement is not mandatory for certain
> package groups.

As far as I know, it's not possible to enforce otp per group is it?
That would be a nice enhancement. 

Additionally, right now, packagers commit with ssh keys or oidc tokens,
in order for a 2fa setup to be effective, we would need to switch that
to kerberos or the like.

> > * I'd really prefer to avoid going back to certs. People have all kinds
> > of problems with certs. I think it would cause a lot of confusion.
> > (Unless I am misunderstanding what use is proposed for them).
> > 
> > > If Fedora contributors would have had access to Fedora's FreeIPA web UI
> > 
> > We actually do have external access to the web UI.
> > We just don't advertise it much.
> 
> Ok, that's good to hear in case we need to experiment with our accounts
> before the Fedora Accounts UI is expanded to cover other authentication
> methods.

Yep. 

> > > or IPA API directly, we wouldn't even need to have a conversation about
> > > PKINIT and certificates. We could have added instructions how to request
> > > and associate a certificate with your account. But since Fedora Accounts
> > > system is the frontend to Fedora Project's FreeIPA deployment, we cannot
> > > simply do that. However, FreeIPA-wise, smartcards are supported now for
> > > Kerberos authentication, so we as Fedora contributors could benefit from
> > > that.
> > 
> > What would this use of certificates do here?
> > Authenticate you to get a kerberos ticket?
> > Allow you to login to the account interface?
> 
> The former. I am only considering all of this to allow Kerberos
> authentication with stronger methods. Smartcards are more accessible
> these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
> (Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
> a smartcard is typically your government-issued ID in many countries.
> 
> Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
> enough to a lower boundary.

Yeah, it will still be hard to require 100% of packagers, but it might
be doable.

> Anyway, using a soft-based smartcard e.g. using NSS database stored on a
> usb flash drive and accessible via PKCS11 could also be an option. The
> problem here is to attest to a server side it is protected by the client
> but this is a common problem to all different methods. Even storing a
> key-pair on your hard drive would work with Kerberos PKINIT without any
> problem.
> 
> > CentOS folks still use certs for their koji:
> > https://wiki.centos.org/Authentication#TLS_certificate
> > (and thats using the same account system/ipa servers as fedora).
> > 
> > > I hope we can plan to work together on this improvement again, similar
> > > how we did with the initial rewrite of Fedora Accounts on top of
> > > FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> > > perhaps CPA team could consider scheduling this effort as part of the
> > > initiatives.
> > 
> > Yeah, I would like that. Perhaps we could setup a meeting soon and
> > dicuss plans? I'm open to video meeting, but we could also do IRC to
> > keep things more open...
> 
> I am open to it too, may be in couple weeks or so, to allow interested
> parties to prepare.

Sure. Can you schedule something when you are ready/available and we can
go from there. 

> > > Let me round up methods that we have supported now or plan to add in
> > > Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
> > > issuance of a Kerberos ticket that can be used for communicating with
> > > the rest of Fedora services:
> > >  - basic password-based authentication
> > >  - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself  - use of an
> > > external RADIUS server for validation of a string passed as
> > >a 'password' or 'token' value
> > >  - use of a certificate stored on a supported PKCS11 token (smartcard,
> > >softtoken (SoftHSMv2, NSS) or just in plain keypair files)
> > >  - use of OAuth2 device authorization grant against some OAuth2 IdP (new
> > >in FreeIPA 4.9.10+)
> > >  - (future) use of a FIDO2/WebAuthn token
> > > 
> > > Fedora accounts system implements the management of the first two
> > > methods right now.
> > 
> > And possibly the 3rd...
> > 
> > What does 'device' mean in the 4th one? :)
> 
> It is part of OAuth 2.0 specifications, 'Device Authorization Grant
> 

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/15/22 08:57, Stephen Smoogen wrote:
> On Wed, 14 Sept 2022 at 18:36, Simo Sorce  wrote:
> 
>> On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:
>>> On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:

 On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen
  wrote:
> I'm not entirely convinced. See this paper:
> https://eprint.iacr.org/2020/1298.pdf

 I only read the abstract of this paper, but looks like the researchers
 have found that FIDO is indeed unphishable. Seems their attack relies
 on websites allowing downgrade to weaker forms of 2FA.
>>>
>>> Yup. The thrust of the paper is: in the real world FIDO2 is usually
>>> deployed alongside older/weaker forms of 2FA, so an attacker can
>>> pretend to the victim that FIDO auth didn't work and convince them to
>>> try a weaker method instead, then phish that.
>>>
>>> Which is a reasonable point, but not necessarily relevant to us. We
>>> *could* require only strong auth and not have weaker fallback methods.
>>
>> So I have been thinking about this, how do you deal with the inevitable
>> fact that keys get lost or stop working if there is no alternative
>> authentication method?
>>
>>
> Inevitable is usually about 4 to 5 emails a week to ad...@fedorproject.org
> from someone unable to log in and saying they lost their phone, token or
> other things. This is out of the couple hundred accounts currently with two
> factor enabled.

Does that mean that individual 2FA devices last 200/5 = 40 weeks on average?

>> I guess people can enroll 2 separate keys (if Feodra Infra will allow
>> that), but not everyone has the means to do that.
>>
>>
> Basically the system would have to enforce that you have to have a GPG key
> and verify that the system can decode a message from the person. Then all
> that security is left to how many developers set their gpg password to
> '123456' or 'password1' and then upload their secret keys to public
> websites so it is convenient for them. From relevant experience with
> Fedora, that number is non-zero.

Yeah, the only solution to *that* is a hardware token with remote
attestation.  That allows one to ensure that the user could not reveal
their secret key even if they wanted to.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Stephen Smoogen]

On Wed, 14 Sept 2022 at 18:36, Simo Sorce  wrote:

> On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:
> > On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:
> > >
> > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen
> > >  wrote:
> > > > I'm not entirely convinced. See this paper:
> > > > https://eprint.iacr.org/2020/1298.pdf
> > >
> > > I only read the abstract of this paper, but looks like the researchers
> > > have found that FIDO is indeed unphishable. Seems their attack relies
> > > on websites allowing downgrade to weaker forms of 2FA.
> >
> > Yup. The thrust of the paper is: in the real world FIDO2 is usually
> > deployed alongside older/weaker forms of 2FA, so an attacker can
> > pretend to the victim that FIDO auth didn't work and convince them to
> > try a weaker method instead, then phish that.
> >
> > Which is a reasonable point, but not necessarily relevant to us. We
> > *could* require only strong auth and not have weaker fallback methods.
>
> So I have been thinking about this, how do you deal with the inevitable
> fact that keys get lost or stop working if there is no alternative
> authentication method?
>
>
Inevitable is usually about 4 to 5 emails a week to ad...@fedorproject.org
from someone unable to log in and saying they lost their phone, token or
other things. This is out of the couple hundred accounts currently with two
factor enabled.



> I guess people can enroll 2 separate keys (if Feodra Infra will allow
> that), but not everyone has the means to do that.
>
>
Basically the system would have to enforce that you have to have a GPG key
and verify that the system can decode a message from the person. Then all
that security is left to how many developers set their gpg password to
'123456' or 'password1' and then upload their secret keys to public
websites so it is convenient for them. From relevant experience with
Fedora, that number is non-zero.



-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On ke, 14 syys 2022, Kevin Fenzi wrote:

On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote:

On ke, 14 syys 2022, Stephen Smoogen wrote:
> On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy 
> wrote:
>
> >
> > Sadly, it cannot be just 'any' certificate, it has to be issued by a
> > certificate authority that is trusted by the KDC as well. For example,
> > by FreeIPA CA which is already ran by the Fedora project infrastructure
> > team. An alternative is to set up certificate mapping and validating
> > rules.
> >
> > If someone from Fedora Accounts team wants to experiment with this, I
> > can guide you what to do.
> >
>
> There is no continual running Fedora Accounts 'team'. There are 2-3 system
> administrators split between releng, operations and  continual
> firefighting. There are also a team of developers who are split between
> CentOS Stream initiatives and other work. Changes like this need to have
> more than just an 'oh I have finally an afternoon free where all the other
> crap in the build infra is actually working for once.. lets dive into IPA'

I understand all of that myself. I think what is important here is to
plan to work together so that eventually we can implement this.


Right and while I agree with what smooge says there, I'm definitely
interested in improving things as we can. I really would prefer a
detailed plan however, not 'lets enable everything we can and see what
sticks'. :)


Oh, for sure 'enable everything' is not what I or others suggest either.
;)




This whole thread is about agreeing or disagreeing whether Fedora as a
project would want to have better security methods to identify and
authenticate its contributors when performing tasks that have large
impact.


Yep. I'm in agreement that we want to... but there's always tradeoffs.

A few random things to mention:

* I don't think requiring FIDO2 for all packagers is tenable. It may
well be that we could get donations or funding to get hardware for all
packagers, especially if we wait for the current inactive process to
finish, but even so, we will run into problems of people who can't get
one shipped to them or gets lost in the mail, etc. There would also be a
delay "hey, you are now a packager, look for a token in the mail in the
next few weeks before you can do anything"


Proven packagers seem to be a fair category to address. Also packagers
responsible for security-related bits of the distribution. Compilers?

There is probably a value in defining what functions critical to have
strongly authenticated and identified to the distribution at large. For
example, right now even 2FA OTP requirement is not mandatory for certain
package groups.



* I'd really prefer to avoid going back to certs. People have all kinds
of problems with certs. I think it would cause a lot of confusion.
(Unless I am misunderstanding what use is proposed for them).


If Fedora contributors would have had access to Fedora's FreeIPA web UI


We actually do have external access to the web UI.
We just don't advertise it much.


Ok, that's good to hear in case we need to experiment with our accounts
before the Fedora Accounts UI is expanded to cover other authentication
methods.




or IPA API directly, we wouldn't even need to have a conversation about
PKINIT and certificates. We could have added instructions how to request
and associate a certificate with your account. But since Fedora Accounts
system is the frontend to Fedora Project's FreeIPA deployment, we cannot
simply do that. However, FreeIPA-wise, smartcards are supported now for
Kerberos authentication, so we as Fedora contributors could benefit from
that.


What would this use of certificates do here?
Authenticate you to get a kerberos ticket?
Allow you to login to the account interface?


The former. I am only considering all of this to allow Kerberos
authentication with stronger methods. Smartcards are more accessible
these days than, say, FIDO2 tokens. A card reader cost is around 10EUR
(Amazon.de gives me ~100 options of USB smartcard readers below 20EUR),
a smartcard is typically your government-issued ID in many countries. 


Though with Token2 FIDO2 tokens that cost 14EUR themselves we get close
enough to a lower boundary.

Anyway, using a soft-based smartcard e.g. using NSS database stored on a
usb flash drive and accessible via PKCS11 could also be an option. The
problem here is to attest to a server side it is protected by the client
but this is a common problem to all different methods. Even storing a
key-pair on your hard drive would work with Kerberos PKINIT without any
problem.


CentOS folks still use certs for their koji:
https://wiki.centos.org/Authentication#TLS_certificate
(and thats using the same account system/ipa servers as fedora).


I hope we can plan to work together on this improvement again, similar
how we did with the initial rewrite of Fedora Accounts on top of
FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
perhaps CPA 

Re: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Wed, 2022-09-14 at 15:49 -0700, Adam Williamson wrote:
> The hardcore way is to say "welp, too bad, your account's gone,
> create
> a new one and start over, including going through the maintainer
> process again", but that might be a bit *too* hardcore.
> 
> This is a perennial issue, though, and the weakest point of the whole
> FIDO2 concept overall, including in the way it's being promoted to a
> mass audience as password-less auth for everything. The official
> story
> is you should also enrol a backup phone or tablet or something that
> you
> keep at home, then if you lose your main phone, you can get into the
> system with the backup device, enrol a new main device, and unenrol
> the
> lost/stolen main device.
> 
> But if you *aren't* rich enough to have spare phones/tablets lying
> around the place, or you just manage to lose both, the story is
> basically "you go into an Apple store or call up Google or Samsung
> etc.
> and somehow convince them you are you and they will then auth a new
> device onto your account". So, awkward squishy human processes again.

To follow up on some of these points, IIRC the weakest chain in the
link is alternate factors (SMS is strictly inferior to TOTP for
example) and social engineering (poorly trained tech support or they
just don't care). A sufficiently advanced attacker may not even have to
take over an account to create a legitimate looking phishing e-mail or
phone call. There's been recent stories of hackers having insider
knowledge that would normally be difficult to obtain for less
sophisticated attackers. I think the first step would be to create a
threat model and then go from there, incorporating all of the points
brought up in this thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Wed, 2022-09-14 at 18:35 -0400, Simo Sorce wrote:
> On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:
> > On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:
> > > 
> > > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen 
> > >  wrote:
> > > > I'm not entirely convinced. See this paper:
> > > > https://eprint.iacr.org/2020/1298.pdf
> > > 
> > > I only read the abstract of this paper, but looks like the researchers 
> > > have found that FIDO is indeed unphishable. Seems their attack relies 
> > > on websites allowing downgrade to weaker forms of 2FA.
> > 
> > Yup. The thrust of the paper is: in the real world FIDO2 is usually
> > deployed alongside older/weaker forms of 2FA, so an attacker can
> > pretend to the victim that FIDO auth didn't work and convince them to
> > try a weaker method instead, then phish that.
> > 
> > Which is a reasonable point, but not necessarily relevant to us. We
> > *could* require only strong auth and not have weaker fallback methods.
> 
> So I have been thinking about this, how do you deal with the inevitable
> fact that keys get lost or stop working if there is no alternative
> authentication method?
> 
> I guess people can enroll 2 separate keys (if Feodra Infra will allow
> that), but not everyone has the means to do that.

Same way you deal with people losing their passwords or current 2FA
tokens: slowly and awkwardly. Basically, have a human deal with it, and
establish as best they can that the person claiming they lost their
tokens really is the person who ought to have them.

Of course, if you do issue new tokens, send an alert about this to all
known contact methods for the account, so if it *was* an Evil Person
doing it, and the Evil Person hasn't also compromised all of those
contact methods too, the Real Packager will know something funky has
happened and - hopefully - reach out and get the account frozen again.

The hardcore way is to say "welp, too bad, your account's gone, create
a new one and start over, including going through the maintainer
process again", but that might be a bit *too* hardcore.

This is a perennial issue, though, and the weakest point of the whole
FIDO2 concept overall, including in the way it's being promoted to a
mass audience as password-less auth for everything. The official story
is you should also enrol a backup phone or tablet or something that you
keep at home, then if you lose your main phone, you can get into the
system with the backup device, enrol a new main device, and unenrol the
lost/stolen main device.

But if you *aren't* rich enough to have spare phones/tablets lying
around the place, or you just manage to lose both, the story is
basically "you go into an Apple store or call up Google or Samsung etc.
and somehow convince them you are you and they will then auth a new
device onto your account". So, awkward squishy human processes again.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Simo Sorce]

On Wed, 2022-09-14 at 15:11 -0700, Adam Williamson wrote:
> On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:
> > 
> > On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen 
> >  wrote:
> > > I'm not entirely convinced. See this paper:
> > > https://eprint.iacr.org/2020/1298.pdf
> > 
> > I only read the abstract of this paper, but looks like the researchers 
> > have found that FIDO is indeed unphishable. Seems their attack relies 
> > on websites allowing downgrade to weaker forms of 2FA.
> 
> Yup. The thrust of the paper is: in the real world FIDO2 is usually
> deployed alongside older/weaker forms of 2FA, so an attacker can
> pretend to the victim that FIDO auth didn't work and convince them to
> try a weaker method instead, then phish that.
> 
> Which is a reasonable point, but not necessarily relevant to us. We
> *could* require only strong auth and not have weaker fallback methods.

So I have been thinking about this, how do you deal with the inevitable
fact that keys get lost or stop working if there is no alternative
authentication method?

I guess people can enroll 2 separate keys (if Feodra Infra will allow
that), but not everyone has the means to do that.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Wed, 2022-09-14 at 10:25 -0500, Michael Catanzaro wrote:
> 
> On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen 
>  wrote:
> > I'm not entirely convinced. See this paper:
> > https://eprint.iacr.org/2020/1298.pdf
> 
> I only read the abstract of this paper, but looks like the researchers 
> have found that FIDO is indeed unphishable. Seems their attack relies 
> on websites allowing downgrade to weaker forms of 2FA.

Yup. The thrust of the paper is: in the real world FIDO2 is usually
deployed alongside older/weaker forms of 2FA, so an attacker can
pretend to the victim that FIDO auth didn't work and convince them to
try a weaker method instead, then phish that.

Which is a reasonable point, but not necessarily relevant to us. We
*could* require only strong auth and not have weaker fallback methods.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Wed, Sep 14, 2022 at 05:47:46PM +0300, Alexander Bokovoy wrote:
> On ke, 14 syys 2022, Stephen Smoogen wrote:
> > On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy 
> > wrote:
> > 
> > > 
> > > Sadly, it cannot be just 'any' certificate, it has to be issued by a
> > > certificate authority that is trusted by the KDC as well. For example,
> > > by FreeIPA CA which is already ran by the Fedora project infrastructure
> > > team. An alternative is to set up certificate mapping and validating
> > > rules.
> > > 
> > > If someone from Fedora Accounts team wants to experiment with this, I
> > > can guide you what to do.
> > > 
> > 
> > There is no continual running Fedora Accounts 'team'. There are 2-3 system
> > administrators split between releng, operations and  continual
> > firefighting. There are also a team of developers who are split between
> > CentOS Stream initiatives and other work. Changes like this need to have
> > more than just an 'oh I have finally an afternoon free where all the other
> > crap in the build infra is actually working for once.. lets dive into IPA'
> 
> I understand all of that myself. I think what is important here is to
> plan to work together so that eventually we can implement this.

Right and while I agree with what smooge says there, I'm definitely
interested in improving things as we can. I really would prefer a
detailed plan however, not 'lets enable everything we can and see what
sticks'. :) 

> This whole thread is about agreeing or disagreeing whether Fedora as a
> project would want to have better security methods to identify and
> authenticate its contributors when performing tasks that have large
> impact.

Yep. I'm in agreement that we want to... but there's always tradeoffs. 

A few random things to mention: 

* I don't think requiring FIDO2 for all packagers is tenable. It may
well be that we could get donations or funding to get hardware for all
packagers, especially if we wait for the current inactive process to
finish, but even so, we will run into problems of people who can't get
one shipped to them or gets lost in the mail, etc. There would also be a
delay "hey, you are now a packager, look for a token in the mail in the
next few weeks before you can do anything"

* I'd really prefer to avoid going back to certs. People have all kinds
of problems with certs. I think it would cause a lot of confusion.
(Unless I am misunderstanding what use is proposed for them).

> If Fedora contributors would have had access to Fedora's FreeIPA web UI

We actually do have external access to the web UI. 
We just don't advertise it much.

> or IPA API directly, we wouldn't even need to have a conversation about
> PKINIT and certificates. We could have added instructions how to request
> and associate a certificate with your account. But since Fedora Accounts
> system is the frontend to Fedora Project's FreeIPA deployment, we cannot
> simply do that. However, FreeIPA-wise, smartcards are supported now for
> Kerberos authentication, so we as Fedora contributors could benefit from
> that.

What would this use of certificates do here? 
Authenticate you to get a kerberos ticket? 
Allow you to login to the account interface?

CentOS folks still use certs for their koji:
https://wiki.centos.org/Authentication#TLS_certificate
(and thats using the same account system/ipa servers as fedora).

> I hope we can plan to work together on this improvement again, similar
> how we did with the initial rewrite of Fedora Accounts on top of
> FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
> perhaps CPA team could consider scheduling this effort as part of the
> initiatives.

Yeah, I would like that. Perhaps we could setup a meeting soon and
dicuss plans? I'm open to video meeting, but we could also do IRC to
keep things more open... 

> Let me round up methods that we have supported now or plan to add in
> Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
> issuance of a Kerberos ticket that can be used for communicating with
> the rest of Fedora services:
>  - basic password-based authentication
>  - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself  - use of an
> external RADIUS server for validation of a string passed as
>a 'password' or 'token' value
>  - use of a certificate stored on a supported PKCS11 token (smartcard,
>softtoken (SoftHSMv2, NSS) or just in plain keypair files)
>  - use of OAuth2 device authorization grant against some OAuth2 IdP (new
>in FreeIPA 4.9.10+)
>  - (future) use of a FIDO2/WebAuthn token
> 
> Fedora accounts system implements the management of the first two
> methods right now.

And possibly the 3rd... 

What does 'device' mean in the 4th one? :) 
We do have https pushes using oauth/oidc token right now. 

Also, once we upgrade src.fedoraproject.org/pkgs.fedoraproject.org from
RHEL8 to RHEL9, it will be possible to use ecdsa-sk and ed25519-sk ssh
keys and thus use FIDO2 for ssh actions if we wish.

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 14/09/2022 17:26, Michael Catanzaro wrote:
If you want to protect against *both* threats, use a security key, but 
you've already pushed back against requiring a hardware purchase.


I never click on links from emails, instant messengers, etc.

I'm using fkinit and my simple custom systemd user timer to keep my 
Kerberos ticket up to date.



I don't want to buy a smartphone just to do TOTP: no way.


KeePassXC supports TOTP, HOTP and Steam 2FA.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Michael Catanzaro]

TLS client certificates is actually not a terrible idea. They're not 
very popular anymore, but they're supported by all major browsers (I 
think?) and they work.


On Wed, Sep 14 2022 at 02:08:32 PM +0200, Vitaly Zaitsev via devel 
 wrote:

On 14/09/2022 10:01, Demi Marie Obenour wrote:

Still, even a pure software FIDO2 implementation is much better than
TOTP etc.


I don't think so. Malware can easily steal the private key. Simple 
TOTP

on a separate device is much better.


Well they're different threats with different solutions. Installing 
malware on users' computers is a lot harder than phishing them, so I'd 
much rather see software-based FIDO2 than TOTP on a separate device. At 
least I'm not aware of any malware running on my computer, but I 
already confessed to entering a password into a phishing website, so we 
know you can phish me at least. If you want to protect against *both* 
threats, use a security key, but you've already pushed back against 
requiring a hardware purchase.


It's impossible to enforce use of a separate device regardless of 
whether you're doing TOTP or FIDO2. I use my Yubikey only for my 
highest-security work account. Everything else uses a TOTP app running 
on-device, vulnerable to malware. (I don't want to buy a smartphone 
just to do TOTP: no way. A $25 security key sounds much more 
reasonable.)


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Michael Catanzaro]

On Wed, Sep 14 2022 at 06:58:12 AM +, Tommy Nguyen 
 wrote:

I'm not entirely convinced. See this paper:
https://eprint.iacr.org/2020/1298.pdf


I only read the abstract of this paper, but looks like the researchers 
have found that FIDO is indeed unphishable. Seems their attack relies 
on websites allowing downgrade to weaker forms of 2FA.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On ke, 14 syys 2022, Stephen Smoogen wrote:

On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy 
wrote:



Sadly, it cannot be just 'any' certificate, it has to be issued by a
certificate authority that is trusted by the KDC as well. For example,
by FreeIPA CA which is already ran by the Fedora project infrastructure
team. An alternative is to set up certificate mapping and validating
rules.

If someone from Fedora Accounts team wants to experiment with this, I
can guide you what to do.



There is no continual running Fedora Accounts 'team'. There are 2-3 system
administrators split between releng, operations and  continual
firefighting. There are also a team of developers who are split between
CentOS Stream initiatives and other work. Changes like this need to have
more than just an 'oh I have finally an afternoon free where all the other
crap in the build infra is actually working for once.. lets dive into IPA'


I understand all of that myself. I think what is important here is to
plan to work together so that eventually we can implement this.

This whole thread is about agreeing or disagreeing whether Fedora as a
project would want to have better security methods to identify and
authenticate its contributors when performing tasks that have large
impact.

If Fedora contributors would have had access to Fedora's FreeIPA web UI
or IPA API directly, we wouldn't even need to have a conversation about
PKINIT and certificates. We could have added instructions how to request
and associate a certificate with your account. But since Fedora Accounts
system is the frontend to Fedora Project's FreeIPA deployment, we cannot
simply do that. However, FreeIPA-wise, smartcards are supported now for
Kerberos authentication, so we as Fedora contributors could benefit from
that.

I hope we can plan to work together on this improvement again, similar
how we did with the initial rewrite of Fedora Accounts on top of
FreeIPA. Again, if this is deemed to be valuable to Fedora contributors,
perhaps CPA team could consider scheduling this effort as part of the
initiatives.

Let me round up methods that we have supported now or plan to add in
Fedora 38-39 timeframe, from FreeIPA and SSSD side. All these lead to
issuance of a Kerberos ticket that can be used for communicating with
the rest of Fedora services:
 - basic password-based authentication
 - use of 2FA HOTP/TOTP tokens implemented by FreeIPA itself 
 - use of an external RADIUS server for validation of a string passed as

   a 'password' or 'token' value
 - use of a certificate stored on a supported PKCS11 token (smartcard,
   softtoken (SoftHSMv2, NSS) or just in plain keypair files)
 - use of OAuth2 device authorization grant against some OAuth2 IdP (new
   in FreeIPA 4.9.10+)
 - (future) use of a FIDO2/WebAuthn token

Fedora accounts system implements the management of the first two
methods right now.


As much as I enjoy better security, everyone should remember that the ones
affected are either packagers who are volunteering to make spec files for
software they need for something else.. or developers who only look at spec
files as the last hassle they need to do before they can mark on their list
'shipped and done'. Most of them do not package/build things very often,
and it takes years for them to get retrained when some change in the
workflow occurs.


A particular benefit of using Kerberos authentication to Fedora services
is that it does not need to change the workflow for all those things.
Once you've got your ticket, it works against all the services you are
allowed to access. Sure, actual process of obtaining that ticket might
change -- like with 2FA token one needs to get a wrap ticket first --
but the rest is the same.


They are also the only ones around to do the work. Making workflow changes
like adding certificates, tokens, etc may be needed but they are going to
need a lot of documentation, continual training, and coaching to actually
make function. If there is no staff or people available to do this, then
the change will fail hard.


Do we have any statistics of how we stand now that Fedora Accounts is
deployed for more than a year and people were enabled to use 2FA tokens
through it?



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Stephen Smoogen]

On Wed, 14 Sept 2022 at 05:28, Alexander Bokovoy 
wrote:

>
> Sadly, it cannot be just 'any' certificate, it has to be issued by a
> certificate authority that is trusted by the KDC as well. For example,
> by FreeIPA CA which is already ran by the Fedora project infrastructure
> team. An alternative is to set up certificate mapping and validating
> rules.
>
> If someone from Fedora Accounts team wants to experiment with this, I
> can guide you what to do.
>

There is no continual running Fedora Accounts 'team'. There are 2-3 system
administrators split between releng, operations and  continual
firefighting. There are also a team of developers who are split between
CentOS Stream initiatives and other work. Changes like this need to have
more than just an 'oh I have finally an afternoon free where all the other
crap in the build infra is actually working for once.. lets dive into IPA'

As much as I enjoy better security, everyone should remember that the ones
affected are either packagers who are volunteering to make spec files for
software they need for something else.. or developers who only look at spec
files as the last hassle they need to do before they can mark on their list
'shipped and done'. Most of them do not package/build things very often,
and it takes years for them to get retrained when some change in the
workflow occurs.

They are also the only ones around to do the work. Making workflow changes
like adding certificates, tokens, etc may be needed but they are going to
need a lot of documentation, continual training, and coaching to actually
make function. If there is no staff or people available to do this, then
the change will fail hard.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 14/09/2022 10:01, Demi Marie Obenour wrote:

Still, even a pure software FIDO2 implementation is much better than
TOTP etc.


I don't think so. Malware can easily steal the private key. Simple TOTP 
on a separate device is much better.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On ke, 14 syys 2022, Demi Marie Obenour wrote:

On 9/14/22 03:55, Vitaly Zaitsev via devel wrote:

On 14/09/2022 08:46, Demi Marie Obenour wrote:

The only other
non-phishable authentication method is TLS client certificates and
I would be fine with those.


Fedora used to have TLS client certificate authorization (in Koji), but
this has been replaced by Kerberos.


Could Fedora turn on PKINIT or make TLS client certificate authentication
an option again?


I think PKINIT support is active, otherwise you would not be able to use
Anonymous PKINIT for FAST channel wrapping with OTP preauthentication.

All we need is a way to associate a trusted certificate with the user
and have the trust between KDC cert and the client machine where you'd
run kinit:

[1660786] 1663147221.189471: PKINIT client verified DH reply
[1660786] 1663147221.189472: PKINIT client found id-pkinit-san in KDC cert: 
krbtgt/fedoraproject@fedoraproject.org
[1660786] 1663147221.189473: PKINIT client matched KDC principal 
krbtgt/fedoraproject@fedoraproject.org against id-pkinit-san; no EKU check 
required
[1660786] 1663147221.189474: PKINIT client used KDF 2B06010502030602 to compute 
reply key aes256-cts/1D6D
[1660786] 1663147221.189475: Preauth module pkinit (17) (real) returned: 
0/Success

The latter works fine, so we just need to have a certificate in the user
account to use PKINIT, not Anonymous PKINIT. And since we have no direct
access to FreeIPA server behind Fedora Accounts system, Fedora Accounts
should be extended to allow adding a public certificate to the user's
account.

Sadly, it cannot be just 'any' certificate, it has to be issued by a
certificate authority that is trusted by the KDC as well. For example,
by FreeIPA CA which is already ran by the Fedora project infrastructure
team. An alternative is to set up certificate mapping and validating
rules.

If someone from Fedora Accounts team wants to experiment with this, I
can guide you what to do.





since almost every laptop has a TPM.


In some countries (Russia, China and some other countries from the US
export banlist) hardware TPMs are prohibited.


Still, even a pure software FIDO2 implementation is much better than
TOTP etc.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue




--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/13/22 21:37, Tommy Nguyen wrote:
> On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote:
>> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
>> devel@lists.fedoraproject.org> wrote:
>>
>>> On 06/09/2022 19:49, Michael Catanzaro wrote:
 Of course, hardware authenticators would be even more secure, and
 it
 sure seems pretty reasonable to expect that people with commit
 access to
 Fedora packages are able to purchase a $25 or 30€ security key
 [1][2].
> 
> I think most people would find it not reasonable for contributors to an
> open source project to pay any amount of cash, even $25, to gain
> packaging rights. That's tantamount to a membership or entrance fee.

There is a huge difference between accepting contributions from someone
and trusting them with access to a vast number of people’s machines.
Qubes OS accepts contributions from untrusted contributors, but it can
only do so because all code is reviewed by hand before merging, so a
malicious contribution simply will not be accepted.  Fedora, on the other
hand, lacks any means to limit the blast radius of a compromised account
with packaging rights.  Therefore, preventing such a compromise is
critical, and hardware authenticators are currently the best means of
doing so.

In the long term, Fedora should figure out how to avoid having to trust
such a large number of people with such power.  But for now, requiring
**unphishable** 2FA is the best option I am aware of.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/14/22 03:55, Vitaly Zaitsev via devel wrote:
> On 14/09/2022 08:46, Demi Marie Obenour wrote:
>> The only other
>> non-phishable authentication method is TLS client certificates and
>> I would be fine with those.
> 
> Fedora used to have TLS client certificate authorization (in Koji), but 
> this has been replaced by Kerberos.

Could Fedora turn on PKINIT or make TLS client certificate authentication
an option again?

>> since almost every laptop has a TPM.
> 
> In some countries (Russia, China and some other countries from the US 
> export banlist) hardware TPMs are prohibited.

Still, even a pure software FIDO2 implementation is much better than
TOTP etc.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 14/09/2022 08:46, Demi Marie Obenour wrote:

The only other
non-phishable authentication method is TLS client certificates and
I would be fine with those.


Fedora used to have TLS client certificate authorization (in Koji), but 
this has been replaced by Kerberos.



since almost every laptop has a TPM.


In some countries (Russia, China and some other countries from the US 
export banlist) hardware TPMs are prohibited.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 13/09/2022 23:50, Demi Marie Obenour wrote:

Another option is a TPM-based authenticator.  Would this be acceptable?


No. TPM 2.0 chip is a *proprietary* black box. Some of them have known 
critical security vulnerabilities[1].


[1]: 
https://arstechnica.com/gadgets/2021/08/how-to-go-from-stolen-pc-to-network-intrusion-in-30-minutes/


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Wed, 2022-09-14 at 02:46 -0400, Demi Marie Obenour wrote:
> Because FIDO2 is not phishable.  TOTP and HOTP are.  The only other
> non-phishable authentication method is TLS client certificates and
> I would be fine with those.

I'm not entirely convinced. See this paper:
https://eprint.iacr.org/2020/1298.pdf

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/13/22 21:37, Tommy Nguyen wrote:
> On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote:
>> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
>> devel@lists.fedoraproject.org> wrote:
>>
>>> On 06/09/2022 19:49, Michael Catanzaro wrote:
 Of course, hardware authenticators would be even more secure, and
 it
 sure seems pretty reasonable to expect that people with commit
 access to
 Fedora packages are able to purchase a $25 or 30€ security key
 [1][2].
> 
> I think most people would find it not reasonable for contributors to an
> open source project to pay any amount of cash, even $25, to gain
> packaging rights. That's tantamount to a membership or entrance fee. 
> 
> While I think this discussion has gone off the rails, here are my
> thoughts:
> - Why such a focus on FIDO2? It seems that nobody has discussed any
> alternatives. FIDO2 isn't even necessarily universally acclaimed in the
> infosec space

Because FIDO2 is not phishable.  TOTP and HOTP are.  The only other
non-phishable authentication method is TLS client certificates and
I would be fine with those.

> - Why such a focus on devices that cost money? I have 2FA enabled on my
> phone with a free open source TOTP app

Because there is no good software FIDO2 implementation.  This can be
solved with a TPM-backed one, since almost every laptop has a TPM.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Tue, 2022-09-06 at 16:14 -0500, Jonathan Wright via devel wrote:
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
> devel@lists.fedoraproject.org> wrote:
> 
> > On 06/09/2022 19:49, Michael Catanzaro wrote:
> > > Of course, hardware authenticators would be even more secure, and
> > > it
> > > sure seems pretty reasonable to expect that people with commit
> > > access to
> > > Fedora packages are able to purchase a $25 or 30€ security key
> > > [1][2].

I think most people would find it not reasonable for contributors to an
open source project to pay any amount of cash, even $25, to gain
packaging rights. That's tantamount to a membership or entrance fee. 

While I think this discussion has gone off the rails, here are my
thoughts:
- Why such a focus on FIDO2? It seems that nobody has discussed any
alternatives. FIDO2 isn't even necessarily universally acclaimed in the
infosec space
- Why such a focus on devices that cost money? I have 2FA enabled on my
phone with a free open source TOTP app

Seems that Fedora also has no SOP in place for requisitions or funding
devices for its members, otherwise I don't think this discussion would
be taking place. Fedora should probably start there first, because once
you talk about buying keys, do you also talk about buying Thinkpads and
laptops that travel overseas to countries that are on US sanction lists
(this is a slippery slope, but do you see where I'm going with this?)

I think mandating software 2FA at a minimum is not that big of a buy-
in, anything beyond that poses major complications.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/6/22 17:29, Alex Perez wrote:
> Jonathan,
> 
> Your perspective on costs seems extremely developed-country-centric, and
> I'd like to suggest you check your (financial) privilege. I don't know
> where you're from; I'm from the US, but I am well aware of the reality
> of many open source contributors from countries where the exchange rate
> against the US dollar is awful.
> 
> You may not see this sort of cost as a barrier to contribution, but I
> can assure you that other casual contributors may, and likely would. You
> have to realize that the cost of the token isn't necessarily the only
> factor that contributes to the overall cost of obtaining such a device.
> International shipping costs can easily triple this dollar amount, to
> say nothing of other associated costs such as import duties, etc. There
> are plenty of countries where such tokens are not domestically
> available, and must be shipped from abroad.
> 
> This just isn't as simple or straightforward as you seem to want it to
> be. Erecting financial barriers to contribution is dangerous, and has
> unintended consequences.

Yes, this stinks.

Unfortunately, there are no good alternatives I am aware of.  The
closest I can think of is some form of software FIDO2 implementation.
Qubes OS will hopefully have one eventually, but I am not sure
if it will be usable outside of Qubes OS and maybe SpectrumOS.
Another option is a TPM-based authenticator.  Would this be acceptable?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Blaise Pabon]

>From the audience:

In the past,  Yubico has been generous in giving keys to packagers.
If they cannot give keys to all, then maybe we can get a few for those who
need them.

Some of us already have keys.

The barrier to becoming a packager is already high (that is good)
But we should decrease the friction (that is bad).

Shall I bring the matter of donated keys up with the Fedora community
folks, or is that already in the works?

Blaise
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Demi Marie Obenour]

On 9/5/22 16:54, Maxwell G via devel wrote:
> On Monday, September 5, 2022 Peter Robinson wrote:
>>  it would probably be easier to join and become a packager by
>> packaging a random leaf package no one would use, then as a packager
>> pick up an random orphaned package that's in the core distro and then
>> just compromise the distro that way TBH.
> 
> They wouldn't even need to pick up a core package. "Supplements: kernel" 
> would 
> get them far enough...

Only solution I know is to require review of certain changes to
package dependencies, enforced by post-build automated checks.
Not sure which changes should require such review.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Gary Buhrmaster]

On Wed, Sep 7, 2022 at 12:27 PM Petr Pisar  wrote:

> Do people lose their tokens more often than forget their passwords?

Depends on the person, of course.  However, it is
less common that one loses a token and does not
somewhat quickly notice it (especially if it is on their
mobile device, or their computer, or their keyring)
than they lose (having someone else obtain) or
forget their password (especially if the password
is not used often).

In any case, it is considered best practice to have
two strong identifier objects, so that one can replace
a lost/stolen one in one's account.  Sometimes
that second identifier is a set of one time passcodes,
and sometimes that is a second enrolled device,
which can (and should) be stored in a separable
secure location (lockbox, etc.).

Some companies that allow one to turn on strong
identity controls even require one to enroll two
devices and/or obtain your one-time passcodes
before they allow you to enable 2FA.  Requiring
this upfront action is typically easier (for the
individual) than having an option to set up various
recovery mechanisms to recover from lost passwords
(since few apparently do do that in advance) or
for the company to have to re-establish your identity
before resetting your password (which does not
work well at large scales and for free services).



In any case, until SSSD/FreeIPA supports the
advanced capabilities (somewhat soon-ish), and
the enhancements or replacement of Ipsilon
occurs to support that, this is all just theoretical.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Michael Catanzaro]

On Tue, Sep 6 2022 at 10:53:03 PM -0500, Maxwell G  
wrote:
I have 2FA set up on my account and it works okay. You'd use `fkinit` 
instead
of `kinit` that requires special setup[1] to work with 2FA. It 
doesn't work
with the GOA kerberos integration. When authenticating with Fedora 
online
services, there's a field for the token just like on any other site 
that

supports 2FA.


OK, well thanks for confirming my worst fears. :/ I'm not interested in 
manual use kinit or fkinit (which I've never heard of). Needs smooth 
integration with gnome-online-accounts.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Wed, Sep 07, 2022 at 08:53:15AM -0400, Stephen Smoogen napsal(a):
> On Wed, 7 Sept 2022 at 08:27, Petr Pisar  wrote:
> > Shouldn't we instead start with strengthening the credentials reset even
> > for password-only authentication? I.e. disallowing the reset. Or enabling
> > having multiple passwords.
> >
> >
> Maybe. What work do you not want done in Fedora for the next couple of years
> to do this. There are a lot of 'OMG we need this' initiatives and very few
> volunteers who have the skill level to help anymore.
> 
> That said, having multiple passwords without additional tokens attached is
> a security nightmare. I have dealt with 6 systems which had them because
> people thought it would cut down work and it either ramped up work or ended
> up with security compromises which were horrible. Disallowing resets end up
> requiring about 2-3 people whose main job every couple of minutes is to go
> through some form to try and confirm a person is who they are and then reset
> manually. You are welcome to take that over as your full time job.
> 
My idea of disallowing reset is no reset. That does not mean somobody will
manually reset records in a database. It means no way. It means new account,
a different login name and repeating the onboarding process (becoming
a packager, nonresponsive process for the old account, overtaking orphaned
packages).

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vít Ondruch]

Dne 07. 09. 22 v 5:53 Maxwell G via devel napsal(a):

On Tuesday, September 6, 2022 Michael Catanzaro wrote:

Currently I do not have any 2FA enabled
on my Fedora account

I have 2FA set up on my account and it works okay. You'd use `fkinit` instead
of `kinit` that requires special setup[1] to work with 2FA. It doesn't work
with the GOA kerberos integration.



This is sad ^^. Is there any RFE somewhere?


Vít



  When authenticating with Fedora online
services, there's a field for the token just like on any other site that
supports 2FA.


because there's no way to disable it once enabled,
and I'm afraid something will break, so I'm not brave enough to opt in.
I highly doubt I'm alone here.

I'd guess that Infrastructure could disable it for you if you enable it and
then change your mind.

[1]: https://fedoraproject.org/wiki/Infrastructure/
Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Stephen Smoogen]

On Wed, 7 Sept 2022 at 08:27, Petr Pisar  wrote:

> V Wed, Sep 07, 2022 at 07:51:15AM -0400, Stephen Smoogen napsal(a):
> > On Wed, 7 Sept 2022 at 02:53, Adam Williamson <
> adamw...@fedoraproject.org>
> > wrote:
> >
> > > On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:
> > > > On 06/09/2022 23:14, Jonathan Wright wrote:
> > > > > Fedora must be looked at as more than just a "hobby project" even
> > > though
> > > > > it is a hobby for some.
> > > >
> > > > There are many casual maintainers who maintain one or two packages.
> We
> > > > shouldn't force them to leave Fedora.
> > > >
> > > > > It's an OS that many rely on and $25 is a somewhat trivial cost for
> > > improved security.
> > > >
> > > > There are many contributors from countries where $25 is a lot. We
> > > > shouldn't set up financial barriers. This is a dead end.
> > >
> > > I think we kind of have two competing factors here, and it's not much
> > > use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR
> > > B IS IMPORTANT!" and that just going round in circles.
> > >
> > > On the one hand, Fedora is not just a hobby project. It's an important
> > > upstream in the F/OSS ecosystem. Very important downstreams like
> > > CentOS, RHEL, Amazon Linux and others are built out of it. It's
> > > absolutely an attractive target for a supply chain attack. We have an
> > > ethical responsibility to the F/OSS community to harden ourselves
> > > against such attacks, and FIDO2 auth would be a good way to do that.
> > >
> > >
> > So I think all this focusing on FIDO2 as a requirement is the problem. We
> > are looking at least 2-3 years before Fedora Infrastructure could
> actually
> > support it at scale.  This is not just technical support, but needing
> > people to actually handle the problems. We have a hard enough handling
> OTP
> > tokens that people put in and then immediately lose so can't log in or
> > change their accounts. Dealing with 100 developers who only put one token
> > on their system and then promptly lose it after going for a jog etc is
> > going to be a nightmare. [I had to support scientists with one time
> tokens
> > before, and it is a constant 'I lost my token and I need to be verified
> > that I am who I am. Can I get a new token?' etc.]
> >
> > So I am going to say I am in agreement with Vitaly that FIDO2 is not a
> > solution we could support at this time. At most we could support HOTP via
> > yubikey but we would need to be able to make sure
> > 1. That we have some sort of '5 codes which can be used in case of
> > emergency'. These are printed on a screen and that is it.
> > 2. We make sure that people have 2 additional devices attached before OTP
> > is 'enabled'.
> >
> > Otherwise this is going to end in tears even before we tried to get
> 'FIDO2'
> > set up.
> >
> Do people lose their tokens more often than forget their passwords?
>

Yes. People lost or reset their phones or they decided to use one of the
'computer' ones and reinstalled their OS and found woops it's gone.
Normally if we see the person is who they are or are not in a group we need
secondary confirmation they are who they are (aka packagers) we can clear
the token and they can log in afterwards.




> Shouldn't we instead start with strengthening the credentials reset even
> for
> password-only authentication? I.e. disallowing the reset. Or enabling
> having
> multiple passwords.
>
>
Maybe. What work do you not want done in Fedora for the next couple of
years to do this. There are a lot of 'OMG we need this' initiatives and
very few volunteers who have the skill level to help anymore.

That said, having multiple passwords without additional tokens attached is
a security nightmare. I have dealt with 6 systems which had them because
people thought it would cut down work and it either ramped up work or ended
up with security compromises which were horrible. Disallowing resets end up
requiring about 2-3 people whose main job every couple of minutes is to go
through some form to try and confirm a person is who they are and then
reset manually. You are welcome to take that over as your full time job.



> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora 

Re: Inactive packagers to be removed after the F37 release

[Tommy Nguyen]

On Wed, 2022-09-07 at 14:26 +0200, Petr Pisar wrote:
> > So I am going to say I am in agreement with Vitaly that FIDO2 is
> > not a
> > solution we could support at this time. At most we could support
> > HOTP via
> > yubikey but we would need to be able to make sure
> > 1. That we have some sort of '5 codes which can be used in case of
> > emergency'. These are printed on a screen and that is it.
> > 2. We make sure that people have 2 additional devices attached
> > before OTP
> > is 'enabled'.
> > 
> > Otherwise this is going to end in tears even before we tried to get
> > 'FIDO2'
> > set up.
> > 
> Do people lose their tokens more often than forget their passwords?
> How do we deal with a forgotten password now
> ?
> Do we have to strenghten an authenticiation reset with the advent of
> tokens?
> 
> I'm asking because to me it seems that the problem as you painted it
> is not
> about having a token but about resetting authentication credentials.
> 
> Shouldn't we instead start with strengthening the credentials reset
> even for
> password-only authentication? I.e. disallowing the reset. Or enabling
> having
> multiple passwords.
> 
> -- Petr

The security is only as strong as the weakest link. Often times this is
the password or the password reset password. For example, 2FA via SMS
is deprecated, yet some websites allow you to fallback to SMS if you do
not have TOTP available. This is more convenient for users, but
horribly insecure (an attacker can just fallback to the more insecure
option since it's available). The most secure option is to ONLY allow
TOTP, for example, and once it's enabled, lock the user out if they
lose access to their device. Typically companies will verify a user's
identify if they need to reset their 2FA (technically insecure due to
social engineering attacks, which is a problem as of recent). Given
that Fedora is a community project, it may be more feasible to verify
someone's identity than some random corporate support desk, but still
suspectible to social engineering.

Anyway, users are always going to forget their passwords, lose their
devices and want an easy way back in, but making the security weak to
accomodate this just trains bad behaviors I think. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Petr Pisar]

V Wed, Sep 07, 2022 at 07:51:15AM -0400, Stephen Smoogen napsal(a):
> On Wed, 7 Sept 2022 at 02:53, Adam Williamson 
> wrote:
> 
> > On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:
> > > On 06/09/2022 23:14, Jonathan Wright wrote:
> > > > Fedora must be looked at as more than just a "hobby project" even
> > though
> > > > it is a hobby for some.
> > >
> > > There are many casual maintainers who maintain one or two packages. We
> > > shouldn't force them to leave Fedora.
> > >
> > > > It's an OS that many rely on and $25 is a somewhat trivial cost for
> > improved security.
> > >
> > > There are many contributors from countries where $25 is a lot. We
> > > shouldn't set up financial barriers. This is a dead end.
> >
> > I think we kind of have two competing factors here, and it's not much
> > use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR
> > B IS IMPORTANT!" and that just going round in circles.
> >
> > On the one hand, Fedora is not just a hobby project. It's an important
> > upstream in the F/OSS ecosystem. Very important downstreams like
> > CentOS, RHEL, Amazon Linux and others are built out of it. It's
> > absolutely an attractive target for a supply chain attack. We have an
> > ethical responsibility to the F/OSS community to harden ourselves
> > against such attacks, and FIDO2 auth would be a good way to do that.
> >
> >
> So I think all this focusing on FIDO2 as a requirement is the problem. We
> are looking at least 2-3 years before Fedora Infrastructure could actually
> support it at scale.  This is not just technical support, but needing
> people to actually handle the problems. We have a hard enough handling OTP
> tokens that people put in and then immediately lose so can't log in or
> change their accounts. Dealing with 100 developers who only put one token
> on their system and then promptly lose it after going for a jog etc is
> going to be a nightmare. [I had to support scientists with one time tokens
> before, and it is a constant 'I lost my token and I need to be verified
> that I am who I am. Can I get a new token?' etc.]
> 
> So I am going to say I am in agreement with Vitaly that FIDO2 is not a
> solution we could support at this time. At most we could support HOTP via
> yubikey but we would need to be able to make sure
> 1. That we have some sort of '5 codes which can be used in case of
> emergency'. These are printed on a screen and that is it.
> 2. We make sure that people have 2 additional devices attached before OTP
> is 'enabled'.
> 
> Otherwise this is going to end in tears even before we tried to get 'FIDO2'
> set up.
> 
Do people lose their tokens more often than forget their passwords?
How do we deal with a forgotten password now
?
Do we have to strenghten an authenticiation reset with the advent of tokens?

I'm asking because to me it seems that the problem as you painted it is not
about having a token but about resetting authentication credentials.

Shouldn't we instead start with strengthening the credentials reset even for
password-only authentication? I.e. disallowing the reset. Or enabling having
multiple passwords.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Stephen Smoogen]

On Wed, 7 Sept 2022 at 02:53, Adam Williamson 
wrote:

> On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:
> > On 06/09/2022 23:14, Jonathan Wright wrote:
> > > Fedora must be looked at as more than just a "hobby project" even
> though
> > > it is a hobby for some.
> >
> > There are many casual maintainers who maintain one or two packages. We
> > shouldn't force them to leave Fedora.
> >
> > > It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.
> >
> > There are many contributors from countries where $25 is a lot. We
> > shouldn't set up financial barriers. This is a dead end.
>
> I think we kind of have two competing factors here, and it's not much
> use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR
> B IS IMPORTANT!" and that just going round in circles.
>
> On the one hand, Fedora is not just a hobby project. It's an important
> upstream in the F/OSS ecosystem. Very important downstreams like
> CentOS, RHEL, Amazon Linux and others are built out of it. It's
> absolutely an attractive target for a supply chain attack. We have an
> ethical responsibility to the F/OSS community to harden ourselves
> against such attacks, and FIDO2 auth would be a good way to do that.
>
>
So I think all this focusing on FIDO2 as a requirement is the problem. We
are looking at least 2-3 years before Fedora Infrastructure could actually
support it at scale.  This is not just technical support, but needing
people to actually handle the problems. We have a hard enough handling OTP
tokens that people put in and then immediately lose so can't log in or
change their accounts. Dealing with 100 developers who only put one token
on their system and then promptly lose it after going for a jog etc is
going to be a nightmare. [I had to support scientists with one time tokens
before, and it is a constant 'I lost my token and I need to be verified
that I am who I am. Can I get a new token?' etc.]

So I am going to say I am in agreement with Vitaly that FIDO2 is not a
solution we could support at this time. At most we could support HOTP via
yubikey but we would need to be able to make sure
1. That we have some sort of '5 codes which can be used in case of
emergency'. These are printed on a screen and that is it.
2. We make sure that people have 2 additional devices attached before OTP
is 'enabled'.

Otherwise this is going to end in tears even before we tried to get 'FIDO2'
set up.




> On the other hand, you are correct that requiring people to either pay
> money or accept proprietary software at some level in order to
> contribute packages to Fedora would be a barrier to contribution, and
> barriers to contribution suck. We could maybe find a sponsor to send
> *existing* packagers a hardware token, but that still leaves the
> problem of what to do about *new* packagers - find a sponsor willing to
> mail a key to anyone who passes a package review? Well, maybe. What to
> do about country laws and export controls that have been brought up?
> That's another problem.
>
> So, we are in a dilemma without a perfect solution. We either have to
> decide which factor is more important, or find some way to
> compromise/finesse things, like requiring FIDO2 auth only for
> provenpackagers. Or only for commits to critpath packages. (And then
> what to do about Supplements:-style attacks?)
>
> The productive thing to do is discuss which factor is the most
> important, or what the best compromise would be. Not just have two sets
> of people keep repeating at each other that each factor exists.
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Adam Williamson]

On Wed, 2022-09-07 at 08:41 +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 23:14, Jonathan Wright wrote:
> > Fedora must be looked at as more than just a "hobby project" even though 
> > it is a hobby for some.
> 
> There are many casual maintainers who maintain one or two packages. We 
> shouldn't force them to leave Fedora.
> 
> > It's an OS that many rely on and $25 is a somewhat trivial cost for 
> > improved security.
> 
> There are many contributors from countries where $25 is a lot. We 
> shouldn't set up financial barriers. This is a dead end.

I think we kind of have two competing factors here, and it's not much
use Camp A saying "FACTOR A IS IMPORTANT!" and Camp B saying "NO FACTOR
B IS IMPORTANT!" and that just going round in circles.

On the one hand, Fedora is not just a hobby project. It's an important
upstream in the F/OSS ecosystem. Very important downstreams like
CentOS, RHEL, Amazon Linux and others are built out of it. It's
absolutely an attractive target for a supply chain attack. We have an
ethical responsibility to the F/OSS community to harden ourselves
against such attacks, and FIDO2 auth would be a good way to do that.

On the other hand, you are correct that requiring people to either pay
money or accept proprietary software at some level in order to
contribute packages to Fedora would be a barrier to contribution, and
barriers to contribution suck. We could maybe find a sponsor to send
*existing* packagers a hardware token, but that still leaves the
problem of what to do about *new* packagers - find a sponsor willing to
mail a key to anyone who passes a package review? Well, maybe. What to
do about country laws and export controls that have been brought up?
That's another problem.

So, we are in a dilemma without a perfect solution. We either have to
decide which factor is more important, or find some way to
compromise/finesse things, like requiring FIDO2 auth only for
provenpackagers. Or only for commits to critpath packages. (And then
what to do about Supplements:-style attacks?)

The productive thing to do is discuss which factor is the most
important, or what the best compromise would be. Not just have two sets
of people keep repeating at each other that each factor exists.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 23:14, Jonathan Wright wrote:
Fedora must be looked at as more than just a "hobby project" even though 
it is a hobby for some.


There are many casual maintainers who maintain one or two packages. We 
shouldn't force them to leave Fedora.



It's an OS that many rely on and $25 is a somewhat trivial cost for improved 
security.


There are many contributors from countries where $25 is a lot. We 
shouldn't set up financial barriers. This is a dead end.



With your suggestion of sponsors to cover such devices - how does that work for 
new packagers?  It seems pretty impossible to do such a thing and tons of money 
would simply be wasted on packagers that did very little to nothing after 
becoming a packager.


They will be able to request one after they get more than 2 packages.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 07/09/2022 05:54, Maxwell G via devel wrote:

As has already been said, that's not true. Google Authenticator is far from
the only software that supports the TOTP standard.


This is not about simple TOTP, but about FIDO2.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Tomasz Torcz]

On Tue, Sep 06, 2022 at 04:14:52PM -0500, Jonathan Wright via devel wrote:
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
> devel@lists.fedoraproject.org> wrote:
> 
> > On 06/09/2022 19:49, Michael Catanzaro wrote:
> > > Of course, hardware authenticators would be even more secure, and it
> > > sure seems pretty reasonable to expect that people with commit access to
> > > Fedora packages are able to purchase a $25 or 30€ security key [1][2].
> >
> > Having to pay even $25 for a hobby project is not acceptable, IMO. If
> > you want to enforce such a policy, find sponsors and buy devices for all
> > Fedora contributors.
> >
> Fedora must be looked at as more than just a "hobby project" even though it
> is a hobby for some.
> 
> It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.

  What more, this cost would be amortized over multiple projects.  One
hardware key can be used with any number of projects and personal
accounts.


-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote:
> > mobile device
> 
> Requires proprietary Google services.

As has already been said, that's not true. Google Authenticator is far from 
the only software that supports the TOTP standard.

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Michael Catanzaro wrote:
> Currently I do not have any 2FA enabled
> on my Fedora account

I have 2FA set up on my account and it works okay. You'd use `fkinit` instead 
of `kinit` that requires special setup[1] to work with 2FA. It doesn't work 
with the GOA kerberos integration. When authenticating with Fedora online 
services, there's a field for the token just like on any other site that 
supports 2FA.

> because there's no way to disable it once enabled,
> and I'm afraid something will break, so I'm not brave enough to opt in.
> I highly doubt I'm alone here.

I'd guess that Infrastructure could disable it for you if you enable it and 
then change your mind.

[1]: https://fedoraproject.org/wiki/Infrastructure/
Kerberos#How_to_use_kerberos_auth_with_Fedora_Infrastructure
-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Maxwell G via devel]

On Tuesday, September 6, 2022 Vitaly Zaitsev via devel wrote:
> If
> you want to enforce such a policy, find sponsors and buy devices for all
> Fedora contributors.

I kind of agree with this. See what PyPi is doing[1]. I don't think anyone who 
maintains one package should get one, but perhaps provenpackagers or those who 
maintain more than X packages should be required to have *some kind* of MFA 
enabled.

[1]: https://pypi.org/security-key-giveaway/

-- 
Maxwell G (@gotmax23)
Pronouns: He/Him/His

signature.asc
Description: This is a digitally signed message part.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alex Perez]

Jonathan,

Your perspective on costs seems extremely developed-country-centric, and
I'd like to suggest you check your (financial) privilege. I don't know
where you're from; I'm from the US, but I am well aware of the reality
of many open source contributors from countries where the exchange rate
against the US dollar is awful.

You may not see this sort of cost as a barrier to contribution, but I
can assure you that other casual contributors may, and likely would. You
have to realize that the cost of the token isn't necessarily the only
factor that contributes to the overall cost of obtaining such a device.
International shipping costs can easily triple this dollar amount, to
say nothing of other associated costs such as import duties, etc. There
are plenty of countries where such tokens are not domestically
available, and must be shipped from abroad.

This just isn't as simple or straightforward as you seem to want it to
be. Erecting financial barriers to contribution is dangerous, and has
unintended consequences.

Respectfully,
Alex Perez

Jonathan Wright via devel wrote on 9/6/22 2:14 PM:
>
>
> On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel
> mailto:devel@lists.fedoraproject.org>>
> wrote:
>
> On 06/09/2022 19:49, Michael Catanzaro wrote:
> > Of course, hardware authenticators would be even more secure,
> and it
> > sure seems pretty reasonable to expect that people with commit
> access to
> > Fedora packages are able to purchase a $25 or 30€ security key
> [1][2].
>
> Having to pay even $25 for a hobby project is not acceptable, IMO. If
> you want to enforce such a policy, find sponsors and buy devices
> for all
> Fedora contributors.
>
> Fedora must be looked at as more than just a "hobby project" even
> though it is a hobby for some.
>
> It's an OS that many rely on and $25 is a somewhat trivial cost for
> improved security.
>
> With your suggestion of sponsors to cover such devices - how does that
> work for new packagers?  It seems pretty impossible to do such a thing
> and tons of money would simply be wasted on packagers that did very
> little to nothing after becoming a packager.
>
>
> -- 
> Sincerely,
>    Vitaly Zaitsev (vit...@easycoding.org
> )
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
>
>
> -- 
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat 
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Jonathan Wright via devel]

On Tue, Sep 6, 2022 at 3:52 PM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 06/09/2022 19:49, Michael Catanzaro wrote:
> > Of course, hardware authenticators would be even more secure, and it
> > sure seems pretty reasonable to expect that people with commit access to
> > Fedora packages are able to purchase a $25 or 30€ security key [1][2].
>
> Having to pay even $25 for a hobby project is not acceptable, IMO. If
> you want to enforce such a policy, find sponsors and buy devices for all
> Fedora contributors.
>
Fedora must be looked at as more than just a "hobby project" even though it
is a hobby for some.

It's an OS that many rely on and $25 is a somewhat trivial cost for
improved security.

With your suggestion of sponsors to cover such devices - how does that work
for new packagers?  It seems pretty impossible to do such a thing and tons
of money would simply be wasted on packagers that did very little to
nothing after becoming a packager.

>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Vitaly Zaitsev via devel]

On 06/09/2022 19:49, Michael Catanzaro wrote:
Of course, hardware authenticators would be even more secure, and it 
sure seems pretty reasonable to expect that people with commit access to 
Fedora packages are able to purchase a $25 or 30€ security key [1][2].


Having to pay even $25 for a hobby project is not acceptable, IMO. If 
you want to enforce such a policy, find sponsors and buy devices for all 
Fedora contributors.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Kevin Fenzi]

On Tue, Sep 06, 2022 at 07:37:19PM +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 18:36, Kevin Fenzi wrote:
> > For an OTP generating app? I don't see why it would...
> 
> No, for FIDO2 authentication.

https://github.com/ellerh/softfido

But not sure how usable it is. ;) 

Also:

https://blog.hansenpartnership.com/webauthn-in-linux-with-a-tpm-via-the-hid-gadget/

but I am not sure where the real code is...

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inactive packagers to be removed after the F37 release

[Alexander Bokovoy]

On ti, 06 syys 2022, Adam Williamson wrote:

On Tue, 2022-09-06 at 16:47 +, Tommy Nguyen wrote:

On Tue, 2022-09-06 at 18:18 +0200, Vitaly Zaitsev via devel wrote:
> On 06/09/2022 17:00, Gary Buhrmaster wrote:
> > mobile device
>
> Requires proprietary Google services.
>
> > computer
>
> Requires proprietary TPM 2.0 chip.

Hi,

Neither of this is true. For example, I use Raivo on my iOS device
which isn't proprietary.

It seems that your concerns regarding 2FA are based on a number of
misconceptions.

1. That it will cost money

You can generate TOTP codes using password generators, desktop apps, or
even by hand in the command line. It's a simple algorithm that doesn't
even require an Internet connection. However, in order for it to truly
be 2FA, it should be on a separate device (i.e, your phone) though
generating it on the desktop is what people do if they have no external
device.

2. That the algorithm will pose problems in other countries

I'm aware of ITAR and munitions exports, but I'm not convinced SHA1 and
HMAC poses as much of a problem as you say it does, even in
Russia/China.

3. That it requires specialized hardware

Again, not true. See part 1. TOTP should work on any device regardless
of the underlying hardware so long as it supports basic cryptographic
primitives.


This section of the thread seems to be moving rather at cross-purposes.
This was mcatanzaro's original proposal:

"In the long run, we should be moving to require WebAuthn for all
Fedora authentication-related purposes, since it's unphishable. Last
year I entered my GitHub password into a phishing page that was
proxying the real GitHub... if the evil page had gone to just slightly
more effort, it could have easily intercepted a simple TOTP/HOTP
challenge. This is not possible with WebAuthn, which I would say
actually is pretty much equivalent to a security magic bullet."

i.e. it was specifically about moving away from allowing "simple
TOTP/HOTP" 2FA, as it is phishable, and requiring webauthn, of which
Vitaly's points are I believe accurate.


Yep. We are not there yet with regards to this use case being
implemented in Fedora AAA but our goal is to provide an infrastructure
in Fedora 38 for Kerberos and local system integration, hopefully.

Looking at hardware products, a cheapest FIDO2 authenticator I know
about is a Token2 T2F2 FIDO2 and U2F Security Key (10.00 EUR per key
plus shipping costs)[1]. I am in contact with Token2 to see if we can
test this hardware in our SSSD/FreeIPA development.

Google's OpenSK platform is something people already tried to turn into
a FIDO2 virtual authenticator -- see [2] for example of integrating with
QEMU. This is far from being complete and user-friendly.


[1] https://www.token2.eu/shop/product/token2-t2f2-fido2-and-u2f-security-key
[2] https://github.com/google/OpenSK/issues/485

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue