merged from debian-sid

1 files changed, 165 insertions, 0 deletions

diff --git a/doc/examples/apt-https-method-example.conf b/doc/examples/apt-https-method-example.conf
new file mode 100644
index 000000000..0067171bd
--- /dev/null
+++ b/doc/examples/apt-https-method-example.conf
@@ -0,0 +1,165 @@
+/* This file is a sample configuration for apt https method. Configuration
+   parameters found in this example file are expected to be used in main
+   apt.conf file, just like other configuration parameters for different
+   methods (ftp, file, ...).
+
+   This example file starts with a common setup that voluntarily exhibits
+   all available configurations knobs with simple comments. Extended
+   comments on the behavior of the option is provided at the end for
+   better readibility. As a matter of fact, a common configuration file
+   will certainly contain far less elements and benefit of default values
+   for many parameters.
+
+   Because some configuration parameters for apt https method in following
+   examples apply to specific (fictional) repositories, the associated
+   sources.list file is provided here:
+
+   ...
+
+   deb     https://secure.dom1.tld/debian unstable main contrib non-free
+   deb-src https://secure.dom1.tld/debian unstable main contrib non-free
+
+   deb     https://secure.dom2.tld/debian unstable main contrib non-free
+   deb-src https://secure.dom2.tld/debian unstable main contrib non-free
+
+   ...
+
+
+   Some notes on the servers:
+
+    - secure.dom1.tld is freely accessible using https (no client
+      authentication is required).
+    - secure.dom1.tld certificate is part of a multi level PKI, and we
+      want to specifically check the issuer of its certificate. We do
+      not have the constraint for secure.dom2.tld
+    - secure.dom2.tld requires client authentication by certificate
+      to access its content.
+    - The certificate presented by both server have (as expected) a CN that
+      matches their respective DNS names.
+    - It somtimes happens that we had other more generic https available
+      repository to our list. We want the checks to be performed against
+      a common list of anchors (like the one provided by ca-certificates
+      package for instance)
+
+   The sample configuration below basically covers those simpe needs.
+*/
+
+
+// Verify peer certificate and also matching between certificate name
+// and server name as provided in sources.list (default values)
+Acquire::https::Verify-Peer "true";
+Acquire::https::Verify-Host "true";
+
+// Except otherwise specified, use that list of anchors
+Acquire::https::CaInfo     "/etc/ssl/certs/ca-certificates.pem";
+
+// Use a specific anchor and associated CRL. Enforce issuer of
+// server certificate using its cert.
+Acquire::https::secure.dom1.tld::CaInfo     "/etc/apt/certs/ca-dom1-crt.pem";
+
+// Like previous for anchor and CRL, but also provide our
+// certificate and keys for client authentication.
+Acquire::https::secure.dom2.tld::CaInfo  "/etc/apt/certs/ca-dom2-crt.pem";
+Acquire::https::secure.dom2.tld::SslCert "/etc/apt/certs/my-crt.pem";
+Acquire::https::secure.dom2.tld::SslKey  "/etc/apt/certs/my-key.pem";
+
+// No need to downgrade, TLS will be proposed by default. Uncomment
+// to have SSLv3 proposed.
+// Acquire::https::mirror.ipv6.ssi.corp::SslForceVersion "SSLv3";
+
+// No need for more debug if every is fine (default). Uncomment
+// me to get additional information.
+// Debug::Acquire::https "true";
+
+
+/*
+  Options with extended comments:
+
+  Acquire::https[::repo.domain.tld]::CaInfo  "/path/to/ca/certs.pem";
+
+    A string providing the path of a file containing the list of trusted
+    CA certificates used to verify the server certificate. The pointed
+    file is made of the concatenation of the CA certificates (in
+    PEM format) creating the chain used for the verification of the path
+    from the root (self signed one). If the remote server provides the
+    whole chain during the exchange, the file need only contain the root
+    certificate. Otherwise, the whole chain is required.
+
+    If you need to support multiple authorities, the only way is to
+    concatenate everything.
+
+    If None is provided, the default CA bundle used by GnuTLS (apt https
+    method is linked against libcurl-gnutls) is used. At the time of
+    writing, /etc/ssl/certs/ca-certificates.crt.
+
+    If no specific hostname is provided, the file is used by default
+    for all https targets. If a specific mirror is provided, it is
+    used for the https entries in the sources.list file that use that
+    repository (with the same name).
+
+  Acquire::https[::repo.domain.tld]::Verify-Peer "true";
+
+    When authenticating the server, if the certificate verification fails
+    for some reason (expired, revoked, man in the middle, lack of anchor,
+    ...), the connection fails. This is obviously what you want in all
+    cases and what the default value (true) of this option provides.
+
+    If you know EXACTLY what you are doing, setting this option to "false"
+    allow you to skip peer certificate verification and make the exchange
+    succeed. Again, this option is for debugging or testing purpose only.
+    It removes ALL the security provided by the use of SSL.TLS to secure
+    the HTTP exchanges.
+
+  Acquire::https[::repo.domain.tld]::Verify-Host "true";
+
+    The certificate provided by the server during the TLS/SSL exchange
+    provides the identity of the server which should match the DNS name
+    used to access it. By default, as requested by RFC 2818, the name
+    of the mirror is checked against the identity found in the
+    certificate. This default behavior is safe and should not be
+    changed. If you know that the server you are using has a DNS name
+    which does not match the identity in its certificate, you can
+    [report that issue to its administrator or] set the option to
+    "false", which will prevent the comparison to be done.
+
+    The options can be set globally or on a per-mirror basis. If set
+    globally, the DNS name used is the one found in the sources.list
+    file in the https URI.
+
+  Acquire::https[::repo.domain.tld]::SslCert "/path/to/client/cert.pem";
+  Acquire::https[::repo.domain.tld]::SslKey  "/path/to/client/key.pem";
+
+    These two options provides support for client authentication using
+    certificates. They respectively accept the X.509 client certificate
+    in PEM format and the associated client key in PEM format (non
+    encrypted form).
+
+    The options can be set globally (which rarely makes sense) or on a
+    per-mirror basis.
+
+  Acquire::https[::repo.domain.tld]::SslForceVersion "TLSv1";
+
+    This option can be use to select the version which will be proposed
+    to the server. "SSLv3" and "TLSv1" are supported. SSLv2, which is
+    considered insecure anyway is not supported (by gnutls, which is
+    used by libcurl against which apt https method is linked).
+
+    When the option is set to "SSLv3" to have apt propose SSLv3 (and
+    associated sets of ciphersuites) instead of TLSv1 (the default)
+    when performing the exchange. This prevents the server to select
+    TLSv1 and use associated cipheruites. You should probably not use
+    this option except if you know exactly what you are doing.
+
+    Note that the default setting does not guarantee that the server
+    will not select SSLv3 (for ciphersuites and SSL/TLS version as
+    selectio is always done by the server, in the end). It only means
+    that apt will not advertise TLS support.
+
+  Debug::Acquire::https "true";
+
+    This option can be used to show debug information. Because it is
+    quite verbose, it is mainly useful to debug problems in case of
+    failure to connect to a server for some reason. The default value
+    is "false".
+
+*/