It was reported [1],[2] that python-keyring would create its configuration file world-readable. This was corrected upstream, however the first commit only changed the permissions of an existing configuration file [3], which is incomplete. A new bug report [4] indicated which sets the permissions on the keyring storage directory to mode 0700, which would fully protect the files. There are patches attached to [4] that correct this; they've not been pulled into upstream yet. CVE-2012-5578 was assigned to the incomplete fix (via the first patch) of CVE-2012-5577. By the looks of things, python-keyring 0.7 (the current version in Fedora and EPEL) uses standard umask settings when creating files and will use whichever filename/path is provided (it does not have a concept of these storage directories to store data). So it suffers from the same flaw, just in a slight different way. Probably the best place to fix it is here: keyring/backend.py: 373 def _init_file(self): 374 """Init the password file, set the password for it. 375 """ ... 406 407 config_file = open(self.file_path,'w') 408 config.write(config_file) [1] https://bitbucket.org/kang/python-keyring-lib/issue/67/set-go-rwx-on-keyring_passcfg [2] https://bugs.launchpad.net/ubuntu/+source/python-keyring/+bug/1031465 [3] https://bitbucket.org/kang/python-keyring-lib/changeset/049cd181470f1ee6c540e1d64acf1def7b1de0c1 [4] https://bitbucket.org/kang/python-keyring-lib/issue/76/insecure-database-file-permissions
Created python-keyring tracking bugs for this issue Affects: fedora-all [bug 881137] Affects: epel-6 [bug 881138]