Description of problem: When acticating or deactiving a VPN connection, NM puts connection secrets (passwords) in dmesg. This is what I found: [ 51.092532] NetworkManager[930]: keyfile: parsing bla ... [ 51.138031] NetworkManager[930]: destroy_one_secret: destroying <group_password!> [ 51.138042] NetworkManager[930]: destroy_one_secret: destroying <my_password!> [ 51.138053] NetworkManager[930]: keyfile: read connection 'bla' Version-Release number of selected component (if applicable): NM-0.8.999-3.git20110526.fc15 How reproducible: Everytime. Steps to Reproduce: 1. Start or stop a VPN connection 2. tail dmesg
I confirm this. This bug is also mentioned in bug 703136.
Duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=708583 ?
Well, the verbose logging is common in both bug reports but I'm not sure if they're really duplicates. It's possible to fix #703136 without fixing this one (if I got the other report right; I didn't read all of it.)
Bug 703136 was original the inability to connect to vpn using kde NetworkManager. With the latest NetworkManager upgrade, this got fixed. Unfortunately, it introduced this bug, the secret logging. So for what I am concerned, bug 703136 is closed as we can connect to vpn, but now we have this bug! I only indicated that this bug was also mentioned there, but it should be treated here. Also, from my experience, this bug is not related to the component Networkmanager-vpnc, but to NetworkManager. It was only after an upgrade of NetworkManager and NetworkManager-glib that this bug got introduced. NetworkManager-vpnc never changed. The current version numbers I have are NetworkManager-glib-0.8.999-3.git20110526.fc15.x86_64 NetworkManager-0.8.999-3.git20110526.fc15.x86_64 while vpnc remains: NetworkManager-vpnc-0.8.999-2.fc15.x86_64 On the other hand, it can also be vpnc, as I never saw the logs of that one before since it did not work.
The debugging statement that caused this is removed in NetworkManager-0.8.9997-1.git20110531.fc15. Nevertheless, somebody needs to notify users that they may have to clean their log files and possible backups of them. The longer this takes, the more time there is for making this somehow end up somewhere where deleting the secrets is difficult or even impossible -- think of backup tapes (difficult) or WORM media (impossible, e.g. optical media).
*** This bug has been marked as a duplicate of bug 708876 ***
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1943 to this vulnerability. For further information about this issue please proceed to: [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-1943 which is a dedicated Red Hat Bugzilla issue tracking system entry for this.