this is part of the gconf drift introduced in 0.14.3. See comments in related upstream report http://oss.codepoet.no/revelation/issue/77/generating-password-on-rhel6-raises A fresh test user wont experience the preference problem. The question becomes how do we force gconf to load the new gconf keys for an app? Users with existing revelation configurations can blow away .gconf/apps/revelation and relogin to avoid the errors and reconfig revelation in the process. But clearly that is not optimal. If there is a packaging mechanism that I can use..I'm all ears. -jef On Sun, Jun 24, 2012 at 12:17 PM, Tom London <selinux@xxxxxxxxx> wrote: > On Sun, Jun 24, 2012 at 12:57 PM, Jef Spaleta <jspaleta@xxxxxxxxx> wrote: >> Rawhide target scratch build of the upstream tree with the fix. >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=4191839 >> >> I have done a local build and test on an F16 system. Revelation >> informs me that the key file is an old encryption format and requests >> me to resave to update the encryption. >> >> Can someone please do an independent confirmation that this actually >> fixes the underlying issues with the encryption weakness? >> >> There appears to be one potential regression in 0.14.3+ with >> searching...but I think its due to a change in gconf key layout. If >> you experience the search crash...logout/login or shutdown/restart >> and the problem appears to go away. I saw the crash last week on F16 >> and F17 while I was doing initial testing for 0.14.3 test packages >> that I rolled ahead of this security fix landing...but I could not >> duplicate the search traceback again after a system restart... making >> it a bit difficult to track down and squash. >> >> Anyways....I'm inclined to wait for the official release tarball to >> land from upstream tomorrow to push update packages into >> rawhide->F17,F16 testing for release 0.14.4 that rolls in the >> encryption changes. In the meantime anyone who is seriously concerned >> about this, please beat on the on the scratch build and make sure its >> actually a fix. >> >> -jef >> -- > > Haven't checked the crypto changes, but I do notice this spew when I > try 'Edit->Preferences': > > Traceback (most recent call last): > File "/usr/bin/revelation", line 206, in <lambda> > action.connect("activate", lambda w: self.prefs()) > File "/usr/bin/revelation", line 1527, in prefs > dialog.run_unique(Preferences, self, self.config) > File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line > 1324, in run_unique > d = create_unique(dialog, *args) > File "/usr/lib64/python2.7/site-packages/revelation/dialog.py", line > 1282, in create_unique > UNIQUE_DIALOGS[dialog] = dialog(*args) > File "/usr/bin/revelation", line 1623, in __init__ > self.__init_section_password(self.page_general) > File "/usr/bin/revelation", line 1762, in __init_section_password > ui.config_bind(self.config, "passwordgen/punctuation", > self.check_punctuation_chars) > File "/usr/lib64/python2.7/site-packages/revelation/ui.py", line > 182, in config_bind > id = cfg.monitor(key, cb_get, widget) > File "/usr/lib64/python2.7/site-packages/revelation/config.py", line > 150, in monitor > callback(key, self.get(key), userdata) > File "/usr/lib64/python2.7/site-packages/revelation/config.py", line > 129, in get > raise ConfigError > ConfigError > > tom > -- > Tom London > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
