#3046 Password and ssh key reset
Closed: Fixed None Opened 7 years ago by toshio.

We've talked about this in infra and at the Board but haven't had a ticket open to tell what happened yet.

== Abbreviated Overview ==
We had a mandatory password and ssh key change in fas. This is the first global ssh key change event since The Incident (we had a partial ssh key change event to get people off of DSA keys and onto RSA keys in 2008 https://fedorahosted.org/fedora-infrastructure/ticket/540) and the first password change since March 2009 https://fedorahosted.org/fedora-infrastructure/ticket/1195

We performed this in large part because many other Linux related sites have experienced intrusions recently and this was a way that we could assure that passwords that may have been used on both those sites and our own were not being used here. ssh_keys were debated but we finally decided that we should do the same with them as we have no way of telling if someone uploaded their ssh private key to one of those shared servers or if compromised ssh private keys were the vector that was being used to gain access to those machines.

We also took the opportunity to enforce slightly stronger strength checking on passwords (still not very onerous but complying with a paper outlining how long passwords need to be to stop easy brute force attacks) and to hash all new passwords with salted sha256sum instead of salted md5sum.

== Actions Today ==
Today 12-01-2011 was the day after the deadline for FAS users to change passwords and ssh keys. We decided to perform the following steps today:

  • Set to null all ssh keys in FAS that had not been changed since our announcement
  • Set accounts that had not changed passwords since the announcement to inactive. This will cause the accounts to have to reset their fas password via email in order to log in.

I will attach the lists of usernames affected by both of these changes.

== Actions for the Future ==
* Set up a weekly cron job to check that people aren't simply re-enabling their account and uploading their old ssh keys.
* Change passwords for three bot accounts (fcommunity, fedoradummy, and critpathbot) to pick up the new hash
* Orphan packages where the user is inactive and remove inactive users from other package acls

We decided to delay the last of these until January 2012 as it is the only one that isn't easily reversible and the lack of active Fedora Accounts may cause some of the package maintainers in question to reset their passwords and fix their accounts before then. Email bounces due to inactive maintainers losing their fedoraproject.org email aliases will be an issue during this period and we may remove the acls and ownership for some users ahead of our January deadline due to this.


List of users whose account was set to inactive due to unchanged passwd
unchg-pw

List of users who had ssh key cleared due to unchanged ssh key
unchg-ssh

List of packages to orphan in at least one branch
packages-to-orphan.txt

List of packages to orphan with more information: package name, release, owner
packages-to-orphan-in-branch.txt

List of packages losing at least one comaintainer in at least one branch
packages-losing-comaint.txt

Packages losing comaintainers with full information about who the comaintainer is, what acls they will lose, what release this will affect, etc.
packages-losing-comaint-full.txt.gz

SQL queries needed to generate the previous lists of packages to orphan
queries.sql

List of owners/comaint that are either inactive or are no longer in the packager groupd
inactive-owners-comaint.txt

Added all the lists of data as attachments here.

Brief summary:
100 packagers are inactive or have somehow left the packager group
686 packages will be orphaned (2836 package-branches (ie, abe-Fedora16, abe-Fedora15 count as two)
* 572 packages lose a comaintainer (3447 package-branches-acls (ie: abe-Fedora16-wart-commit, and abe-Fedora16-wart-approveacls count as two).

Just out of curiosity -- can you tell us how many of these 686 packages are in the critical path or minimal install set? Those are the ones of most concern to me.

For the packages that will be orphaned, could someone also generate a list of any packages that depend on them? It might help find new maintainers so we don't end up breaking dependencies in F17.

Today jsteffan (zope, plone, pwsafe, blueproximity) reactivated

critpath list:
{{{
row


(boost,bkoz)
(cyrus-sasl,jfch2222)
(cyrus-sasl,plautrba)
(fontconfig,behdad)
(gnome-terminal,behdad)
(json-glib,alexh)
(libcdaudio,athimm)
(libssh2,cweyl)
(libthai,behdad)
(openjpeg,seg)
(pango,behdad)
(perl-common-sense,cweyl)
(perl-Event,cweyl)
(perl-POE,cweyl)
(perl-Test-Simple,cweyl)
(qrencode,taljurf)
(vte,behdad)
(17 rows)
}}}

select distinct (p.name, pl.owner) from package as p, packagelisting as pl, collection as c where p.id = pl.packageid and pl.collectionid = c.id and pl.critpath = true and p.name in ($PKG_LIST);

notting does things like that when preparing for the cyclic removal of orphaned packages. I don't seem to be able to find the script that does that right now but perhaps that could be adapted to find that out what deps will be affected by this.

The packages listed in cweyl-perl.txt have been switched to mmaslano who is a comaintainer. I attempted contact today to be sure that was okay but received no response. If this is undesirable we can orphan all the packages in the list later.

Replying to [comment:6 toshio]:

The packages listed in cweyl-perl.txt have been switched to mmaslano who is a comaintainer. I attempted contact today to be sure that was okay but received no response. If this is undesirable we can orphan all the packages in the list later.

Perhaps we can do the same for the other perl-* packages being orphaned, most of which belonged to iburrel?

In that realm, please consider cpan-upload as well.

We now have a regular cron script to check ssh keys against old data.

This completes all the actions for this ticket and I am going to close it now.

Please re-open if there's any further action to take.

Re-opening this as we have some folks who re-uploaded their same ssh key. ;(

We warned the list of them last week to please clear out their key or upload a new one.

I am going to mark them inactive today, and then in one month (2012-03-27) we can drop the ones that are maintainers from their packages. Hopefully most of them will upload a new key before then.

This is all done. We locked accounts of all those people who failed to upload a new key.

Login to comment on this ticket.

Metadata