Re: Stale proven packagers
On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote: > On Tue, 2020-12-22 at 13:23 -0800, Kevin Fenzi wrote: > > > > > Perhaps we need a process for cleaning up membership of this extremely > > > powerful group? If the FAS password of *any one* of those user accounts > > > were somehow compromised (or if just one of them decided they had a > > > grudge against Fedora now and were going to have some fun), the results > > > could be...unfortunate. > > > > Oh look, flashback 13 years: > > > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > > > Anyhow, I was in favor of something then, but it got shouted down, and I > > am still in favor now of some kind of checkin process. I think it should > > be light weight tho... always being bothered is bad. On the other hand > > it's hard to know how to notify people. If you send email once a week > > for 4 weeks and get no answer does that mean they are missing? Or that > > your email is going to the spam folder? Or that they are on a long > > vacation not checking email? It's hard to balance. > > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. > Proven packagers really should be people who are deeply involved in > Fedora work on a daily basis, I think, and so should be able to respond > to a regular check-in process like this or the one bcotton proposed. > And the result would only be that they'd lose provenpackager > privileges, which could quite easily be restored if it turned out > they'd just gone on a yak farming retreat for a bit or something. The fedora-active-user script also checks the last date/time the user logged into FAS (I should check how that'll work with noggin). This could be re-used here and a simple mechanism to opt-out of the procedure once initiated. Pierre ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote:
> A propos of some discussion of the Solarwinds news, it occurred to me
> to check how many proven packager accounts there are in FAS. There are
> 251, which seems like a lot. Then it occurred to me to check how many
> of them are inactive, so I wrote a little script:
>
> ===
>
> #!/usr/bin/python3
>
> import getpass
>
> from fedora.client.fas2 import AccountSystem
> from koji import ClientSession
>
> username = input("FAS user name: ")
> password = getpass.getpass("FAS password: ")
>
> acc = AccountSystem(username=username, password=password)
> pps = acc.group_members("provenpackager")
>
> ks = ClientSession("https://koji.fedoraproject.org/kojihub;)
> for pp in pps:
> user = ks.getUser(pp["username"])
> if not user:
> print(f"{pp['username']} NON-EXISTENT IN KOJI")
> continue
> uid = user["id"]
> if ks.listBuilds(userID=uid, createdAfter="2019-01-01 00:00:00"):
> continue
> print(pp["username"])
One thing missing there is the check if the account is still active in FAS. In
the case of Seth you'll see it has been disabled for a long time. So there no
security risk with that account.
Pierre
___
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
Re: Stale proven packagers
On Sun, Dec 27, 2020 at 7:38 PM Kevin Fenzi wrote: > You can add more than one. Just put them in a file and upload all of > them for 'ssh key' one key per line. There's a limit based on > applications getting the ssh keys, but you can upload multiple keys > fine. Oh, ok! Thanks. ___ 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
Re: Stale proven packagers
On Wed, Dec 30, 2020 at 12:00:47AM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 28 December 2020 at 03:38, Kevin Fenzi wrote: > > On Sun, Dec 27, 2020 at 06:43:23PM -0700, Ken Dreyer wrote: > > > On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune > > > wrote: > > > > > > > > > The weakest point in the current system is really the FAS password. If > > > > > you have a packager's FAS password you can change the ssh key > > > > > associated with the account to another that you control, and the FAS > > > > > password is also all you need to run a build and submit it to Bodhi. > > > > > > > > Or you add an SSH key without removing the maintainer's keys on the > > > > off chance that it would go unnoticed... > > > > > > From what I can tell, the current implementation of FAS does not allow > > > more than one SSH key per user account. > > > > You can add more than one. Just put them in a file and upload all of > > them for 'ssh key' one key per line. There's a limit based on > > applications getting the ssh keys, but you can upload multiple keys > > fine. > > Is that documented somewhere? I was also under the impression that only > one key was permitted. If you click on the little [i] info thing next to ssh key when editing your account you can see: "Many resources require public key authentication to work. By uploading your public key to us, you can then log in to our servers. Type "man ssh-keygen" for more information on creating your key (it must be an RSA key). Once created you will want to upload ~/.ssh/id_rsa.pub. If you wish to login through several hosts, each with their own public key, you can create a concatenated file of public ssh keys and upload it in lieu of the individual ssh public key. "Warning: In case of having ECDSA key please upload the two types of keys because some of our servers may not accept ECDSA keys." " (The last thing there is wrong now... we have no rhel6 vm's left). 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
Re: Stale proven packagers
On Monday, 28 December 2020 at 03:38, Kevin Fenzi wrote: > On Sun, Dec 27, 2020 at 06:43:23PM -0700, Ken Dreyer wrote: > > On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune > > wrote: > > > > > > > The weakest point in the current system is really the FAS password. If > > > > you have a packager's FAS password you can change the ssh key > > > > associated with the account to another that you control, and the FAS > > > > password is also all you need to run a build and submit it to Bodhi. > > > > > > Or you add an SSH key without removing the maintainer's keys on the > > > off chance that it would go unnoticed... > > > > From what I can tell, the current implementation of FAS does not allow > > more than one SSH key per user account. > > You can add more than one. Just put them in a file and upload all of > them for 'ssh key' one key per line. There's a limit based on > applications getting the ssh keys, but you can upload multiple keys > fine. Is that documented somewhere? I was also under the impression that only one key was permitted. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
Re: Stale proven packagers
On Sun, Dec 27, 2020 at 06:43:23PM -0700, Ken Dreyer wrote: > On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune > wrote: > > > > > The weakest point in the current system is really the FAS password. If > > > you have a packager's FAS password you can change the ssh key > > > associated with the account to another that you control, and the FAS > > > password is also all you need to run a build and submit it to Bodhi. > > > > Or you add an SSH key without removing the maintainer's keys on the > > off chance that it would go unnoticed... > > From what I can tell, the current implementation of FAS does not allow > more than one SSH key per user account. You can add more than one. Just put them in a file and upload all of them for 'ssh key' one key per line. There's a limit based on applications getting the ssh keys, but you can upload multiple keys fine. 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
Re: Stale proven packagers
On Sun, Dec 27, 2020 at 01:11:20PM +, Dridi Boukelmoune wrote: > On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote: > > > > On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > > > The weakest point in the current system is really the FAS password. If > > > > you have a packager's FAS password you can change the ssh key > > > > associated with the account to another that you control, and the FAS > > > > password is also all you need to run a build and submit it to Bodhi. > > > > Well, really the weakest point is email. If you have control over a fas > > accounts email address you can reset the password, etc. > > > > > Or you add an SSH key without removing the maintainer's keys on the > > > off chance that it would go unnoticed... > > > > fas sends email on every such change. > > There are situations where notifications could go unnoticed. At this > point if an attacker managed to compromise an email address and add an > SSH key to a fas account, the attacker might also delete the > notification email promptly. Sure, or reset the password...or change the email address, or pretty much anything. This is why I said "the weakest point is email". We assume someone who controls an email is the same as the person who controls the account associated with that email. 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
Re: Stale proven packagers
On Thu, Dec 24, 2020 at 12:33 AM Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > you have a packager's FAS password you can change the ssh key > > associated with the account to another that you control, and the FAS > > password is also all you need to run a build and submit it to Bodhi. > > Or you add an SSH key without removing the maintainer's keys on the > off chance that it would go unnoticed... From what I can tell, the current implementation of FAS does not allow more than one SSH key per user account. - Ken ___ 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
Re: Stale proven packagers
On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote: > > On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > > The weakest point in the current system is really the FAS password. If > > > you have a packager's FAS password you can change the ssh key > > > associated with the account to another that you control, and the FAS > > > password is also all you need to run a build and submit it to Bodhi. > > Well, really the weakest point is email. If you have control over a fas > accounts email address you can reset the password, etc. > > > Or you add an SSH key without removing the maintainer's keys on the > > off chance that it would go unnoticed... > > fas sends email on every such change. There are situations where notifications could go unnoticed. At this point if an attacker managed to compromise an email address and add an SSH key to a fas account, the attacker might also delete the notification email promptly. Dridi ___ 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
Re: Stale proven packagers
On Sat, Dec 26, 2020 at 10:54 PM Björn Persson wrote: > > Gary Buhrmaster wrote: > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required > > I'm in favor of complementing the FAS passphrase with a second factor. > > I'm against any attempt to require biometrics. These are my reasons: He did say and/or and there's been no official proposal for biometrics, and I very much doubt there will be, I don't see the point in it. > · Biometric identifiers aren't cleanly separated from identity. They > are more akin to your username than to your passphrase. A random key or > a passphrase can be revoked and replaced if it gets out. Fingers and > faces are very difficult to replace. And yes they can get out. Once > your fingerprint has been scanned and turned into data, those data can > be copied like any other secret. You also leave your fingerprints on > everything you touch. > > · Such a requirement is unenforceable. A client can never prove to a > server that it has a certain piece of hardware. It can only prove that > it knows a certain secret – or two secrets since we're talking about > two-factor authentication. Whether the secrets are stored on a hard > disk, in a Yubikey, in somebody's brain or in somebody's retina, is > unknown to the server. Before authentication it must be assumed that > the client may be an attacker who is lying about everything they can > lie about. Some protocol might allow the client to claim that it used a > fingerprint reader, but as far as the server knows the attacker might > just be using a stored scan of the real user's fingerprint. > > · Biometrics is low-grade security for use where convenience takes > precedence. If somebody can't remember a good PIN, then it's better for > them to unlock their phone with their fingerprint than to choose "" > for their PIN. Strong crypto keys and hardware tokens are better where > security requirements are higher, like in two-factor authentication. > Requiring biometrics is effectively the same as prohibiting stronger > authentication methods, which is a stupid thing to do. > > Björn Persson > ___ > 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 ___ 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
Re: Stale proven packagers
Il giorno sab, 26/12/2020 alle 23.53 +0100, Björn Persson ha scritto: > Gary Buhrmaster wrote: > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required > > I'm in favor of complementing the FAS passphrase with a second > factor. > > I'm against any attempt to require biometrics. These are my reasons: I totally agree with you, for the reasons you explained below. > · Biometric identifiers aren't cleanly separated from identity. They > are more akin to your username than to your passphrase. A random key > or > a passphrase can be revoked and replaced if it gets out. Fingers and > faces are very difficult to replace. And yes they can get out. Once > your fingerprint has been scanned and turned into data, those data > can > be copied like any other secret. You also leave your fingerprints on > everything you touch. > > · Such a requirement is unenforceable. A client can never prove to a > server that it has a certain piece of hardware. It can only prove > that > it knows a certain secret – or two secrets since we're talking about > two-factor authentication. Whether the secrets are stored on a hard > disk, in a Yubikey, in somebody's brain or in somebody's retina, is > unknown to the server. Before authentication it must be assumed that > the client may be an attacker who is lying about everything they can > lie about. Some protocol might allow the client to claim that it used > a > fingerprint reader, but as far as the server knows the attacker might > just be using a stored scan of the real user's fingerprint. > > · Biometrics is low-grade security for use where convenience takes > precedence. If somebody can't remember a good PIN, then it's better > for > them to unlock their phone with their fingerprint than to choose > "" > for their PIN. Strong crypto keys and hardware tokens are better > where > security requirements are higher, like in two-factor authentication. > Requiring biometrics is effectively the same as prohibiting stronger > authentication methods, which is a stupid thing to do. Guido Aulisi 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
Re: Stale proven packagers
Gary Buhrmaster wrote: > Arguably those with elevated access (provenpackagers(*)) > should be required to use a hardware token such > as a FIDO2 authenticators with biometrics and/or > PIN required I'm in favor of complementing the FAS passphrase with a second factor. I'm against any attempt to require biometrics. These are my reasons: · Biometric identifiers aren't cleanly separated from identity. They are more akin to your username than to your passphrase. A random key or a passphrase can be revoked and replaced if it gets out. Fingers and faces are very difficult to replace. And yes they can get out. Once your fingerprint has been scanned and turned into data, those data can be copied like any other secret. You also leave your fingerprints on everything you touch. · Such a requirement is unenforceable. A client can never prove to a server that it has a certain piece of hardware. It can only prove that it knows a certain secret – or two secrets since we're talking about two-factor authentication. Whether the secrets are stored on a hard disk, in a Yubikey, in somebody's brain or in somebody's retina, is unknown to the server. Before authentication it must be assumed that the client may be an attacker who is lying about everything they can lie about. Some protocol might allow the client to claim that it used a fingerprint reader, but as far as the server knows the attacker might just be using a stored scan of the real user's fingerprint. · Biometrics is low-grade security for use where convenience takes precedence. If somebody can't remember a good PIN, then it's better for them to unlock their phone with their fingerprint than to choose "" for their PIN. Strong crypto keys and hardware tokens are better where security requirements are higher, like in two-factor authentication. Requiring biometrics is effectively the same as prohibiting stronger authentication methods, which is a stupid thing to do. Björn Persson pgpUh0Z_Vy5p9.pgp Description: OpenPGP digital signatur ___ 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
Re: Stale proven packagers
On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote: > > The weakest point in the current system is really the FAS password. If > > you have a packager's FAS password you can change the ssh key > > associated with the account to another that you control, and the FAS > > password is also all you need to run a build and submit it to Bodhi. Well, really the weakest point is email. If you have control over a fas accounts email address you can reset the password, etc. > Or you add an SSH key without removing the maintainer's keys on the > off chance that it would go unnoticed... fas sends email on every such change. 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:49:10AM +, Peter Robinson wrote: > > Just to expand on this a little. Removing access from people that have > left the project either because they've decided they're able to > continue to contribute (option 1) or because something has triggered > an admin process (option 2) isn't a slight on the person involved in > any of this process and removing a well earned ACL doesn't remove any > of the contributions or the value they provided in the past. Completely agreed! > But we have to realise than inactive accounts may mean associated > inactive email addresses or other things associated with a person > which may be open to compromise as well and we need to protect the > project as a whole as after-all if a fellow contributor has moved on > to better things account is used to comprise everything where does > that leave us? > > Group membership is easily re-instated, trust after a security > compromise not so much! Well, we might need to think about that too though. Say we have a contributor that is very active, in tons of groups. They go inactive. We remove their group membership after a while. Then, years later they appear and send an email from their old gmail account 'Hi, I'm back, please re-add me to all my old groups". How do we know thats really the old contributor vs just someone who reclaimed a old gmail account? but anyhow, lots to consider here... we probibly need to come up with a straw man proposal for everyone to poke holes in after the new year. 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
Re: Stale proven packagers
On 22. 12. 20 21:39, Adam Williamson wrote: Perhaps we need a process for cleaning up membership of this extremely powerful group? If the FAS password of*any one* of those user accounts were somehow compromised (or if just one of them decided they had a grudge against Fedora now and were going to have some fun), the results could be...unfortunate. I've read the thread an I agree. At very least, we should remove the provenpackager membership when we deem somebody nonresponsive (we currently don't). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ 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
Re: Stale proven packagers
On Thu, Dec 24, 2020 at 11:35:03AM +, Peter Robinson wrote: > On Thu, Dec 24, 2020 at 10:43 AM Leigh Scott wrote: > > > > > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > > > > > > > > > > > It does support it, but AFAIK does not require it. > > > > > > Arguably those with elevated access (provenpackagers(*)) > > > should be required to use a hardware token such > > > as a FIDO2 authenticators with biometrics and/or > > > PIN required (some phones with biometrics are > > > are equivalent to external tokens) where passwords > > > themselves can away. That may be a bridge too > > > far at this point, but I would like to see that as a goal > > > to work towards (2021 should be the year passwords > > > die according to Microsoft). > > > > Are fedora going to provide us with the FIDO2 authenticators with > > biometrics hardware? > > My current FIDO U2F key just has a button to press. > > There's apps too Ad biometrics: There currently exists no biometrics authentication option, which has not already been broken, sometimes even before release. This only adds a false sense of security. (Fingerprints can't be just reset/renewed too) Apps are *never* equivalent to physical tokens, as phones do have a direct network connection with exposed services or network submitted code run on the device almost always. Requiring a higher security level for some things is fine, as long as it is not too tedious - otherwise people will write workarounds for it. FIDO2 itself seems to be current thing, but the biometrics option doesn't add anything useful. Ad expiration of pp accounts: Confirmation e.g. once a year by the same person is fine (with appropriate reminder emails/notifications), but as soon as you add more requirements from other persons it makes it more political. All the best, Astra 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
Re: Stale proven packagers
On Thu, Dec 24, 2020 at 10:43 AM Leigh Scott wrote: > > > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > > > > > > > It does support it, but AFAIK does not require it. > > > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required (some phones with biometrics are > > are equivalent to external tokens) where passwords > > themselves can away. That may be a bridge too > > far at this point, but I would like to see that as a goal > > to work towards (2021 should be the year passwords > > die according to Microsoft). > > Are fedora going to provide us with the FIDO2 authenticators with biometrics > hardware? > My current FIDO U2F key just has a button to press. There's apps too ___ 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
Re: Stale proven packagers
> On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > > > It does support it, but AFAIK does not require it. > > Arguably those with elevated access (provenpackagers(*)) > should be required to use a hardware token such > as a FIDO2 authenticators with biometrics and/or > PIN required (some phones with biometrics are > are equivalent to external tokens) where passwords > themselves can away. That may be a bridge too > far at this point, but I would like to see that as a goal > to work towards (2021 should be the year passwords > die according to Microsoft). Are fedora going to provide us with the FIDO2 authenticators with biometrics hardware? My current FIDO U2F key just has a button to press. ___ 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
Re: Stale proven packagers
> The weakest point in the current system is really the FAS password. If > you have a packager's FAS password you can change the ssh key > associated with the account to another that you control, and the FAS > password is also all you need to run a build and submit it to Bodhi. Or you add an SSH key without removing the maintainer's keys on the off chance that it would go unnoticed... ___ 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 8:43 PM Matthew Miller wrote: > I'm not in favor of that -- I think it's generally not the best policy Correct, that is what FIDO2 biometrics are designed to replace entirely. Passwords, in general, must die. > and doesn't address the issue directly. Agreed, as was stated earlier, deal with the ~90 provenpackagers that are no longer active, and then move towards other goals (perhaps with the new-FAS (whenever that rolls out)). ___ 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:06:25PM -0800, Michel Alexandre Salim wrote: > Maybe mandatory password/key rotation is an option? With your account > disabled after a grace period if the password is expired. I'm not in favor of that -- I think it's generally not the best policy¹ and doesn't address the issue directly. 1. https://www.sans.org/security-awareness-training/blog/time-password-expiration-die -- Matthew Miller Fedora Project Leader ___ 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
Re: Stale proven packagers
On Wed, 2020-12-23 at 00:49 +, Peter Robinson wrote: > On Wed, Dec 23, 2020 at 12:37 AM Peter Robinson > wrote: > > > > On Wed, Dec 23, 2020 at 12:20 AM Kevin Fenzi > > wrote: > > > > > > On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > > > > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi > > > > wrote: > > > > > > > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson > > > > > wrote: > > > > > > > > > > > > I think what ever process is run at the point their account > > > > > > is > > > > > > disabled should revoke all privileges, that's a fairly > > > > > > standard IT > > > > > > security procedure. > > > > > > > > > > There's no process for packages/provenpackagers. > > > > > > > > > > We do have a process for infrastructure/sysadmins: > > > > > > > > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > > > > > > > But it only triggers when we _know_ someone isn't > > > > > contributing anymore > > > > > (they tell us, etc). > > > > > > > > How were the accounts disabled though? Is there a process for > > > > that or > > > > how did that happen in this context? > > > > > > Accounts can be disabled two ways: > > > > > > 1. The user logs in and marks the account 'inactive'. To change > > > this > > > back to active they have to reset their password and login again > > > and > > > change it back. > > > > > > 2. An admin can change users to 'disabled' where they cannot > > > change that > > > without intervention. > > > > In both cases all ACLs should be removed, if in the former they > > wish > > to have what ever access back there can be a documented process to > > file a ticket for it. > > Just to expand on this a little. Removing access from people that > have > left the project either because they've decided they're able to > continue to contribute (option 1) or because something has triggered > an admin process (option 2) isn't a slight on the person involved in > any of this process and removing a well earned ACL doesn't remove any > of the contributions or the value they provided in the past. > > But we have to realise than inactive accounts may mean associated > inactive email addresses or other things associated with a person > which may be open to compromise as well and we need to protect the > project as a whole as after-all if a fellow contributor has moved on > to better things account is used to comprise everything where does > that leave us? > Maybe mandatory password/key rotation is an option? With your account disabled after a grace period if the password is expired. We can start with enforcing this for people who have membership in important groups (e.g. provenpackager, sponsors). -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 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
Re: Stale proven packagers
On Wed, 2020-12-23 at 18:04 +0100, Florian Weimer wrote: > * Gary Buhrmaster: > > > It does support it, but AFAIK does not require it. > > > > Arguably those with elevated access (provenpackagers(*)) > > should be required to use a hardware token such > > as a FIDO2 authenticators with biometrics and/or > > PIN required (some phones with biometrics are > > are equivalent to external tokens) where passwords > > themselves can away. That may be a bridge too > > far at this point, but I would like to see that as a goal > > to work towards (2021 should be the year passwords > > die according to Microsoft). > > Is there even meaningful two-factor authentication support for Git > pushes, anywhere? (Not just in the Fedora infrastructure.) I mean, they *kinda* are 2FA already: we use certs and hopefully packagers all have a passphrase, so you need the cert and the passphrase. The weakest point in the current system is really the FAS password. If you have a packager's FAS password you can change the ssh key associated with the account to another that you control, and the FAS password is also all you need to run a build and submit it to Bodhi. -- 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
Re: Stale proven packagers
On Wed, Dec 23, 2020, at 12:04 PM, Florian Weimer wrote: > Is there even meaningful two-factor authentication support for Git > pushes, anywhere? (Not just in the Fedora infrastructure.) This problem is solved by my plan: https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-source-and-pr-driven-workflow For example in OpenShift our projects don't allow direct pushes to master, and merges require review from a second person. The CI bot takes care of merging, not humans. (The 2FA aspect here boils down to web authentication which is well supported) Even for projects I created upstream and am a project owner, once they reach a certain point I still try really really hard to get someone else to review and not just push things to master. ___ 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
Re: Stale proven packagers
* Gary Buhrmaster: > It does support it, but AFAIK does not require it. > > Arguably those with elevated access (provenpackagers(*)) > should be required to use a hardware token such > as a FIDO2 authenticators with biometrics and/or > PIN required (some phones with biometrics are > are equivalent to external tokens) where passwords > themselves can away. That may be a bridge too > far at this point, but I would like to see that as a goal > to work towards (2021 should be the year passwords > die according to Microsoft). Is there even meaningful two-factor authentication support for Git pushes, anywhere? (Not just in the Fedora infrastructure.) Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ___ 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
Re: Stale proven packagers
On Wed, 2020-12-23 at 15:05 +, Gary Buhrmaster wrote: > On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel > wrote: > > > > > Maybe Fedora should add 2FA support and require it for the most powerful > > groups? > > > > It does support it, but AFAIK does not require it. old-FAS (the current one) has 2FA support and requires it for things like root access on infra hosts. There's at least one bug in the old-FAS 2FA implementation which makes it close to useless, so it probably wouldn't be worth extending the requirements for 2FA until new-FAS (based on AAA) is deployed. At that point I think it would make sense to require packager accounts to have a second factor, and require that second factor when getting a Kerberos ticket and when changing the ssh keys on the account. -- 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:49 PM Vitaly Zaitsev via devel wrote: > > Maybe Fedora should add 2FA support and require it for the most powerful > groups? > It does support it, but AFAIK does not require it. Arguably those with elevated access (provenpackagers(*)) should be required to use a hardware token such as a FIDO2 authenticators with biometrics and/or PIN required (some phones with biometrics are are equivalent to external tokens) where passwords themselves can away. That may be a bridge too far at this point, but I would like to see that as a goal to work towards (2021 should be the year passwords die according to Microsoft). And then packager cleanup, while still important, and should be done, might easily be made very lightweight of reconfirming a CLA once a year (as Richard suggested) if one wishes to continue to be a packager (of any type) since the exposure of compromised account is significantly reduced for those using something like FIDO2 with biometrics. (*) and then consider upping the requirements over time down the developer chain, perhaps with the next step(s) being to expand to include others such as those involved in "core security related" software (I am not sure I can categorize that, but I suspect one could come to some consensus, such as the kernel, openssh, glibc, etc.), even if not provenpackagers (although probably most of those people are PPs). ___ 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
Re: Stale proven packagers
On 22.12.2020 21:39, Adam Williamson wrote: Perhaps we need a process for cleaning up membership of this extremely powerful group? If the FAS password of*any one* of those user accounts were somehow compromised (or if just one of them decided they had a grudge against Fedora now and were going to have some fun), the results could be...unfortunate. Maybe Fedora should add 2FA support and require it for the most powerful groups? -- 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 03:55:22PM -0500, Ben Cotton wrote: > On Tue, Dec 22, 2020 at 3:44 PM Adam Williamson > wrote: > > > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? > > Yes, please. I think we should split the issue in two: handling the long list of _currently_ inactive pps, and the ongoing cleanup after that. No matter what we decide for the second, I think we should remove pp privs for the ~90 accounts with no builds in the last two years "immediately" (i.e. e.g. some time in early January). Zbyszek > > I'll even go out on a limb and propose a process... > > > At a point (TBD) in each release cycle members of the provenpackager group > > who have not submitted a koji build in the last six months will be > > contacted via their @fedoraproject.org email address to verify that they > > should remain in the provenpackager group. If they do not acknowledge > > within two weeks, they will be removed from the provenpackager group. > > I'm not particularly tied to any of the values above, but it's a > start. Arguably, it should be more than a "yes, please keep me in", > but we can see how it goes for a few releases before tightening it > down. I'd like to make it minimally annoying to start, but something > more than we have now. I'm also open to other mechanisms other than > email (and the list could also be shared to devel-announce to help > make it more visible). > > I don't really care where in the cycle we do it. I don't think one > spot is particularly better than another. I assume FESCo won't approve > anything before mid-January, and it's probably good to start this > sooner rather than later, so maybe around branch day (9 Feb for Fedora > 34) is as good a place as any? > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > 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 ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 3:47 PM Richard Shaw wrote: > On Tue, Dec 22, 2020 at 2:40 PM Adam Williamson < > adamw...@fedoraproject.org> wrote: > >> >> Perhaps we need a process for cleaning up membership of this extremely >> powerful group? If the FAS password of *any one* of those user accounts >> were somehow compromised (or if just one of them decided they had a >> grudge against Fedora now and were going to have some fun), the results >> could be...unfortunate. >> > > I mentioned it once but got zero response... What about requiring a CLA > (or something like it) annually instead of one time. This would help clean > up inactive packagers as well. > > This seems like a reasonable solution to me. > Thanks, > Richard > ___ > 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 > ___ 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:37 AM Peter Robinson wrote: > > On Wed, Dec 23, 2020 at 12:20 AM Kevin Fenzi wrote: > > > > On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > > > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > > > > > I think what ever process is run at the point their account is > > > > > disabled should revoke all privileges, that's a fairly standard IT > > > > > security procedure. > > > > > > > > There's no process for packages/provenpackagers. > > > > > > > > We do have a process for infrastructure/sysadmins: > > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > > > > > But it only triggers when we _know_ someone isn't contributing anymore > > > > (they tell us, etc). > > > > > > How were the accounts disabled though? Is there a process for that or > > > how did that happen in this context? > > > > Accounts can be disabled two ways: > > > > 1. The user logs in and marks the account 'inactive'. To change this > > back to active they have to reset their password and login again and > > change it back. > > > > 2. An admin can change users to 'disabled' where they cannot change that > > without intervention. > > In both cases all ACLs should be removed, if in the former they wish > to have what ever access back there can be a documented process to > file a ticket for it. Just to expand on this a little. Removing access from people that have left the project either because they've decided they're able to continue to contribute (option 1) or because something has triggered an admin process (option 2) isn't a slight on the person involved in any of this process and removing a well earned ACL doesn't remove any of the contributions or the value they provided in the past. But we have to realise than inactive accounts may mean associated inactive email addresses or other things associated with a person which may be open to compromise as well and we need to protect the project as a whole as after-all if a fellow contributor has moved on to better things account is used to comprise everything where does that leave us? Group membership is easily re-instated, trust after a security compromise not so much! Peter ___ 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
Re: Stale proven packagers
On Wed, Dec 23, 2020 at 12:20 AM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > > > I think what ever process is run at the point their account is > > > > disabled should revoke all privileges, that's a fairly standard IT > > > > security procedure. > > > > > > There's no process for packages/provenpackagers. > > > > > > We do have a process for infrastructure/sysadmins: > > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > > > But it only triggers when we _know_ someone isn't contributing anymore > > > (they tell us, etc). > > > > How were the accounts disabled though? Is there a process for that or > > how did that happen in this context? > > Accounts can be disabled two ways: > > 1. The user logs in and marks the account 'inactive'. To change this > back to active they have to reset their password and login again and > change it back. > > 2. An admin can change users to 'disabled' where they cannot change that > without intervention. In both cases all ACLs should be removed, if in the former they wish to have what ever access back there can be a documented process to file a ticket for it. > Of course all this may be different in the new account system coming > soon. :) Let's hope there's some hooks to provide that functionality :) ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 11:22:17PM +, Peter Robinson wrote: > On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > > > I think what ever process is run at the point their account is > > > disabled should revoke all privileges, that's a fairly standard IT > > > security procedure. > > > > There's no process for packages/provenpackagers. > > > > We do have a process for infrastructure/sysadmins: > > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > > > But it only triggers when we _know_ someone isn't contributing anymore > > (they tell us, etc). > > How were the accounts disabled though? Is there a process for that or > how did that happen in this context? Accounts can be disabled two ways: 1. The user logs in and marks the account 'inactive'. To change this back to active they have to reset their password and login again and change it back. 2. An admin can change users to 'disabled' where they cannot change that without intervention. Of course all this may be different in the new account system coming soon. :) 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 11:02 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > > > I think what ever process is run at the point their account is > > disabled should revoke all privileges, that's a fairly standard IT > > security procedure. > > There's no process for packages/provenpackagers. > > We do have a process for infrastructure/sysadmins: > https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html > > But it only triggers when we _know_ someone isn't contributing anymore > (they tell us, etc). How were the accounts disabled though? Is there a process for that or how did that happen in this context? ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 10:29:11PM +, Peter Robinson wrote: > > I think what ever process is run at the point their account is > disabled should revoke all privileges, that's a fairly standard IT > security procedure. There's no process for packages/provenpackagers. We do have a process for infrastructure/sysadmins: https://docs.pagure.org/infra-docs/sysadmin-guide/sops/departing-admin.html But it only triggers when we _know_ someone isn't contributing anymore (they tell us, etc). 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 9:58 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote: > > > > So that proposal was just for all packagers. I think it should at least > > be reasonable to set a relatively high bar for being a provenpackager. > > That predates the existance of the provenpackager group, so yeah. ;) > > > Proven packagers really should be people who are deeply involved in > > Fedora work on a daily basis, I think, and so should be able to respond > > to a regular check-in process like this or the one bcotton proposed. > > And the result would only be that they'd lose provenpackager > > privileges, which could quite easily be restored if it turned out > > they'd just gone on a yak farming retreat for a bit or something. > > Perhaps it could just be 'hey, go do a scratch build and you will drop > off the list to be dropped'. I personally don't think that's a high enough bar to retain proven packager, I think people should be actively involved in the project. > Or possibly related to this, we could send everyone a email on their fas > birthday, asking them to look at what groups they are involved with and > adjust (a yearly bit of introspection we could all probibly do with). That doesn't work TBH, people don't actively drop privs "just in case", we should have some real stats behind this, we're better off being active in the adjustment of things like this rather than attempting to bold the gate shut long after the horses have bolted! ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 9:23 PM Kevin Fenzi wrote: > > On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote: > > A propos of some discussion of the Solarwinds news, it occurred to me > > to check how many proven packager accounts there are in FAS. There are > > 251, which seems like a lot. Then it occurred to me to check how many > > of them are inactive, so I wrote a little script: > > ...snip... > > > > > that's 90 of the 251 who still have provenpackager privileges, but > > haven't run any kind of Koji build since at least 2019-01-01 (if you > > check, it turns out many of them haven't run a build since long before > > then). Many of them, to my knowledge, don't work on Fedora at all any > > more and haven't for years. At least one of them, to my and everyone > > else's knowledge, is sadly dead and has been for some time. One account > > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > > exist in koji (any more?) > > Do note that some of these people have accounts and group memebership, > but their accounts in fas are disabled/inactive. I think what ever process is run at the point their account is disabled should revoke all privileges, that's a fairly standard IT security procedure. > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? If the FAS password of *any one* of those user accounts > > were somehow compromised (or if just one of them decided they had a > > grudge against Fedora now and were going to have some fun), the results > > could be...unfortunate. > > Oh look, flashback 13 years: > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > Anyhow, I was in favor of something then, but it got shouted down, and I > am still in favor now of some kind of checkin process. I think it should > be light weight tho... always being bothered is bad. On the other hand > it's hard to know how to notify people. If you send email once a week > for 4 weeks and get no answer does that mean they are missing? Or that > your email is going to the spam folder? Or that they are on a long > vacation not checking email? It's hard to balance. > > 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 ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020, 2:39 PM Adam Williamson wrote: > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. Agreed that there's a higher bar here. I think the privilege should be revoked if you've not built anything in Koji for one year. - Ken ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 01:39:26PM -0800, Adam Williamson wrote: > > So that proposal was just for all packagers. I think it should at least > be reasonable to set a relatively high bar for being a provenpackager. That predates the existance of the provenpackager group, so yeah. ;) > Proven packagers really should be people who are deeply involved in > Fedora work on a daily basis, I think, and so should be able to respond > to a regular check-in process like this or the one bcotton proposed. > And the result would only be that they'd lose provenpackager > privileges, which could quite easily be restored if it turned out > they'd just gone on a yak farming retreat for a bit or something. Perhaps it could just be 'hey, go do a scratch build and you will drop off the list to be dropped'. Or possibly related to this, we could send everyone a email on their fas birthday, asking them to look at what groups they are involved with and adjust (a yearly bit of introspection we could all probibly do with). 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
Re: Stale proven packagers
On Tue, 2020-12-22 at 13:23 -0800, Kevin Fenzi wrote: > > > Perhaps we need a process for cleaning up membership of this extremely > > powerful group? If the FAS password of *any one* of those user accounts > > were somehow compromised (or if just one of them decided they had a > > grudge against Fedora now and were going to have some fun), the results > > could be...unfortunate. > > Oh look, flashback 13 years: > > https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal > > Anyhow, I was in favor of something then, but it got shouted down, and I > am still in favor now of some kind of checkin process. I think it should > be light weight tho... always being bothered is bad. On the other hand > it's hard to know how to notify people. If you send email once a week > for 4 weeks and get no answer does that mean they are missing? Or that > your email is going to the spam folder? Or that they are on a long > vacation not checking email? It's hard to balance. So that proposal was just for all packagers. I think it should at least be reasonable to set a relatively high bar for being a provenpackager. Proven packagers really should be people who are deeply involved in Fedora work on a daily basis, I think, and so should be able to respond to a regular check-in process like this or the one bcotton proposed. And the result would only be that they'd lose provenpackager privileges, which could quite easily be restored if it turned out they'd just gone on a yak farming retreat for a bit or something. -- 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 12:39:56PM -0800, Adam Williamson wrote: > A propos of some discussion of the Solarwinds news, it occurred to me > to check how many proven packager accounts there are in FAS. There are > 251, which seems like a lot. Then it occurred to me to check how many > of them are inactive, so I wrote a little script: ...snip... > > that's 90 of the 251 who still have provenpackager privileges, but > haven't run any kind of Koji build since at least 2019-01-01 (if you > check, it turns out many of them haven't run a build since long before > then). Many of them, to my knowledge, don't work on Fedora at all any > more and haven't for years. At least one of them, to my and everyone > else's knowledge, is sadly dead and has been for some time. One account > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > exist in koji (any more?) Do note that some of these people have accounts and group memebership, but their accounts in fas are disabled/inactive. > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. Oh look, flashback 13 years: https://fedoraproject.org/wiki/User:JesseKeating/AutomatedMIAProposal?rd=JesseKeating/AutomatedMIAProposal Anyhow, I was in favor of something then, but it got shouted down, and I am still in favor now of some kind of checkin process. I think it should be light weight tho... always being bothered is bad. On the other hand it's hard to know how to notify people. If you send email once a week for 4 weeks and get no answer does that mean they are missing? Or that your email is going to the spam folder? Or that they are on a long vacation not checking email? It's hard to balance. 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 3:44 PM Adam Williamson wrote: > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? Yes, please. I'll even go out on a limb and propose a process... > At a point (TBD) in each release cycle members of the provenpackager group > who have not submitted a koji build in the last six months will be contacted > via their @fedoraproject.org email address to verify that they should remain > in the provenpackager group. If they do not acknowledge within two weeks, > they will be removed from the provenpackager group. I'm not particularly tied to any of the values above, but it's a start. Arguably, it should be more than a "yes, please keep me in", but we can see how it goes for a few releases before tightening it down. I'd like to make it minimally annoying to start, but something more than we have now. I'm also open to other mechanisms other than email (and the list could also be shared to devel-announce to help make it more visible). I don't really care where in the cycle we do it. I don't think one spot is particularly better than another. I assume FESCo won't approve anything before mid-January, and it's probably good to start this sooner rather than later, so maybe around branch day (9 Feb for Fedora 34) is as good a place as any? -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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
Re: Stale proven packagers
On 12/22/20 2:39 PM, Adam Williamson wrote: epienbro In this case this individual has passed away. :( His packages were reassigned, but I don't think we have a process for taking care of the rest of an individual's resources (accounts, groups, etc.). ___ 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
Re: Stale proven packagers
On Tue, 22 Dec 2020 at 21:40, Adam Williamson wrote: > that's 90 of the 251 who still have provenpackager privileges, but > haven't run any kind of Koji build since at least 2019-01-01 (if you > check, it turns out many of them haven't run a build since long before > then). Many of them, to my knowledge, don't work on Fedora at all any > more and haven't for years. At least one of them, to my and everyone > else's knowledge, is sadly dead and has been for some time. One account > - it's Greg Dekoenigsberg - somehow is in the FAS pp group but doesn't > exist in koji (any more?) > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. > Security implications are one thing, but it's also unfortunate that these accounts (and related packages) exist in limbo. Would it perhaps make sense to extend/improve your script, run it once every half a year and contact the packagers to check with them whether they're still interested in Fedora? Best, Andy ___ 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
Re: Stale proven packagers
On Tue, Dec 22, 2020 at 2:40 PM Adam Williamson wrote: > > Perhaps we need a process for cleaning up membership of this extremely > powerful group? If the FAS password of *any one* of those user accounts > were somehow compromised (or if just one of them decided they had a > grudge against Fedora now and were going to have some fun), the results > could be...unfortunate. > I mentioned it once but got zero response... What about requiring a CLA (or something like it) annually instead of one time. This would help clean up inactive packagers as well. Thanks, Richard ___ 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
