Removing x-x509-user-cert mime handler.

net/base/mime_util.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include <algorithm>
 #include <iterator>
 #include <map>
 #include <string>
 
 #include "base/containers/hash_tables.h"
@@ skipping 341 matching lines @@
   return g_mime_util.Get().GetMimeTypeFromFile(file_path, mime_type);
 }
 
 bool GetWellKnownMimeTypeFromExtension(const base::FilePath::StringType& ext,
                                        std::string* mime_type) {
   return g_mime_util.Get().GetWellKnownMimeTypeFromExtension(ext, mime_type);
 }
 
 bool GetPreferredExtensionForMimeType(const std::string& mime_type,
                                       base::FilePath::StringType* extension) {
+  // Force .crt extension for client certificates.

[Ryan Sleevi, 2015/12/01 22:45:47]

Shouldn't this only be for ChromeOS, and embedded in the logic of
platform_mime_util_linux.cc for OS_CHROMEOS?

[svaldez, 2015/12/01 22:53:36]

Not entirely sure whether we want to limit this to only OS_CHROMEOS. Linux needs
it since there's no good default handler, and other OS might need it since
otherwise we are going to typically end up downloading files with no extension,
since the filename probably isn't set for application/x-x509-user-cert files.

[Ryan Sleevi, 2015/12/01 23:00:50]

My (opinionated, potentially wrong) thinking is that Linux, forcing a download
and having them import via chrome://settings/certificates is fine. The Linux UI
isn't the 'canonical' way to manage the NSS store, and there's plenty of other
ways depending on distro (p11-kit on RHEL-and-derivatives come to mind)

So since Linux is such a special snowflake of having use cases, it seems like we
should just let it be a download and let the user handle. Supporting device
enrollment for Linux is a bit of a 'non-goal' anyways.
Yeah, but that will have issues w/ other browsers anyways, so I'm inclined to
take the simple path of leaving the extension unmolested. I mention this because
a .crt extension will trigger different behaviour on different platforms
(Windows in particular), where you might be importing a PKCS#7 file (which
Windows likes to do as .p7b - to indicate PKCS#7 binary, *shrug*)

Is the extension mangling even necessary now, given
https://codereview.chromium.org/1423663012/diff/140001/chrome/browser/downloa...
? It doesn't seem like it is - we can just leave it extensionless (if the server
happened to not set one)

[svaldez, 2015/12/01 23:05:22]

The problem in that case is that since we'll end up with extensionless
downloads, the user would have to change the file type in the open dialog in the
certificate manager to be "All Files" instead of the default we have now. Though
I suppose that might encourage users of client certificates to start setting a
Content-Disposition on the files so that they download with the right file name.

+  if (mime_type == "application/x-x509-user-cert") {
+    *extension = FILE_PATH_LITERAL("crt");
+    return true;
+  }
+
   return g_mime_util.Get().GetPreferredExtensionForMimeType(mime_type,
                                                             extension);
 }
 
 bool MatchesMimeType(const std::string& mime_type_pattern,
                      const std::string& mime_type) {
   return g_mime_util.Get().MatchesMimeType(mime_type_pattern, mime_type);
 }
 
 bool ParseMimeTypeWithoutParameter(const std::string& type_string,
@@ skipping 208 matching lines @@
   post_data->append("\r\n" + value + "\r\n");
 }
 
 void AddMultipartFinalDelimiterForUpload(const std::string& mime_boundary,
                                          std::string* post_data) {
   DCHECK(post_data);
   post_data->append("--" + mime_boundary + "--\r\n");
 }
 
 }  // namespace net