Indeed, this is really annoying. I have to keep a bunch of files around, while the majority of configuration options is in gconf.

Hm, I need to keep my user certificate files around anyway, for my LDAP and SMTP/POP3 authentication. Putting them in the keyring isn't any help there; this doesn't seem to be as great an idea as you seem to think. Why would anyone move/delete these files?

Howard, your comment assumes a few things that are not always true.
1. That the user is using a single cert for multiple services
2. That a user actually knows *what* a certificate is.

The use case looks like this:
1. John doesn't know what a cert is
2. His admin gives him a file and says "put this in the cert box"
3. Three months later, John is cleaning up his files.  He sees the cert file, doen't remember what it is, opens it, the contents appear to be gibberish and so he figures the file is garbage and deletes it.
4. John reboots his computer and the network doesn't work.  "Why!?"

It would be *better* for NM to make a copy of the cert at the time the connection is created and store the cert for the length of the connection's configuration.  If the config is delete, the cert should be deleted as well.

Yeah, we should be copying it for now and later integrating with certificate stores that may be present  (and smartcards where we can't get the private key!).

(In reply to comment #3)
> Howard, your comment assumes a few things that are not always true.
> 1. That the user is using a single cert for multiple services
> 2. That a user actually knows *what* a certificate is.

Sure, but you seem to be assuming those are never true...

> The use case looks like this:
> 1. John doesn't know what a cert is
> 2. His admin gives him a file and says "put this in the cert box"
> 3. Three months later, John is cleaning up his files.  He sees the cert file,
> doen't remember what it is, opens it, the contents appear to be gibberish and
> so he figures the file is garbage and deletes it.
> 4. John reboots his computer and the network doesn't work.  "Why!?"

There are hundreds if not thousands of files that Gnome depends on that look like gibberish, but nobody seems to be worried about any of them being accidentally deleted. (e.g. %gconf.xml) Most likely because they're stored in a special location, and most users just ignore that location.

It makes sense to make sure that the cert is stored somewhere that it won't easily be accidentally deleted, sure. But this is too specific a solution. It would be better to define a standard location in a user's home directory for storing all of their user certs, which can be relied on by various other software that uses certs. Just like all cert-based software now can rely on the systemwide /etc/ssl/certs.

In case it's not obvious, I'm suggesting:
  make sure ~/.ssl exists, with restricted permissions
  require the user to move their cert into ~/.ssl

The idea of copying the cert from the specified path into any other backing store is problematic for at least two reasons:
  1) any time you duplicate security credentials, you create the potential for a new security hole. I.e., this idea is fundamentally unsound.
  2) violates the principle of least astonishment. If I later come back and copy a new certificate over the old one (it expired, or was revoked, whatever) and NM still continues to use its private copy, things won't work and I'll have no idea why not.

This will eventually be implemented by letting you import certificates into the PKCS#11 database (eg, gnome-keyring), and them reading them from there rather than from the filesystem.

*** This bug has been marked as a duplicate of bug 719982 ***