openswan: Request for review
Dear members of the mailing list,
please find attached the template and control file of the openswan-package. Both have been heavily reworked in the last few weeks and due to their age they are in deep need of a review. I know all of you are busy due to squeeze deadline but as this package should be up-to-date for release I hope you find some time for checking it.
Thanks in advance and kind regards
Harald Jenny
Source: openswan
Section: net
Priority: optional
Maintainer: Rene Mayrhofer <rmayr@debian.org>
Uploaders: Harald Jenny <harald@a-little-linux-box.at>
Standards-Version: 3.8.4
Vcs-Browser: http://svn.debian.org/viewsvn/pkg-openswan
Vcs-Svn: svn://svn.debian.org/svn/pkg-openswan
Build-Depends: debhelper (>= 7.1), libgmp3-dev, libssl-dev (>= 0.9.8), htmldoc, man2html, libcurl4-openssl-dev, libopensc2-dev, libldap2-dev, libpam0g-dev, libkrb5-dev, bison, flex, dpatch, bzip2, po-debconf
Homepage: http://www.openswan.org/
Package: openswan
Architecture: any
Pre-Depends: debconf | debconf-2.0
Depends: ${shlibs:Depends}, ${misc:Depends}, bsdmainutils, openssl, host, iproute, iproute (>=20041019-0.1) | ipsec-tools
Suggests: openswan-modules-source, curl
Provides: ike-server
Conflicts: freeswan (<< 2.04-12)
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
The Openswan IKE daemon is named pluto. It was inherited from the FreeS/WAN
project, but provides improved X.509 certificate support and other features.
.
In order to use the KLIPS IPsec code instead of the native one, you will
need to install openswan-modules-source and build the respective module for
your kernel.
Package: openswan-dbg
Architecture: any
Section: debug
Priority: extra
Depends: ${misc:Depends}, openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - debugging symbols
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package provides the symbols needed for debugging of openswan
binaries.
Package: openswan-doc
Architecture: all
Section: doc
Suggests: openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - documentation
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package provides the free parts of the documentation for Openswan.
Package: openswan-modules-source
Architecture: all
Section: kernel
Depends: ${misc:Depends}, debhelper, bzip2
Recommends: module-assistant | kernel-package, linux-headers | linux-source
Suggests: openswan
Homepage: http://www.openswan.org/
Description: Internet Protocol Security kernel module source
This package contains the source code for the Openswan IPsec kernel module,
which is required to support the old-style KLIPS ipsecX network interfaces.
.
Please note that kernel versions >= 2.6.23 do not need to be patched anymore
in order to provide NAT Traversal support for KLIPS.
.
With this package, modules for different kernel images can be built manually
or using tools like module-assistant or kernel-package.
Package: openswan-modules-dkms
Architecture: all
Section: kernel
Depends: ${misc:Depends}, dkms, openswan
Homepage: http://www.openswan.org/
Description: Internet Protocol Security kernel module source (DKMS)
This package contains the source code for the Openswan IPsec kernel module,
which is required to support the old-style KLIPS ipsecX network interfaces.
.
Please note that kernel versions >= 2.6.23 do not need to be patched anymore
in order to provide NAT Traversal support for KLIPS.
.
With this package, modules for local kernel images are automatically built
and installed every time upgrades of relevant kernel packages are installed.
Template: openswan/runlevel_changes
Type: note
_Description: Old runlevel management superseded
Previous versions of the Openswan package allowed the user to choose between
three different Start/Stop-Levels. Due to changes in the standard system
startup procedure, this is no longer necessary and useful. For all new
installations as well as old ones running in any of the predefined modes,
sane default levels set will now be set. If you are upgrading from a previous
version and changed your Openswan startup parameters, then please take a
look at NEWS.Debian for instructions on how to modify your setup accordingly.
Template: openswan/restart
Type: boolean
Default: true
_Description: Do you wish to restart Openswan?
Restarting Openswan is a good idea, since if there is a security fix, it
will not be fixed until the daemon restarts. Most people expect the daemon
to restart, so this is generally a good idea. However, this might take down
existing connections and then bring them back up (including the connection
currently used for this update, so it is recommended not to restart if you
are using any of the tunnel for administration).
Template: openswan/install_x509_certificate
Type: boolean
Default: false
_Description: Do you want to use a X509 certificate for this host?
This installer can automatically create or import a X509 certificate for
this host. It can be used to authenticate IPsec connections to other hosts
and is the preferred way for building up secure IPsec connections. The other
possibility would be to use shared secrets (passwords that are the same on
both sides of the tunnel) for authenticating an connection, but for a larger
number of connections, key based authentication is easier to administer and
more secure.
.
If you do not want to this now you can answer "No" and later use the command
"dpkg-reconfigure openswan" to come back.
Template: openswan/how_to_get_x509_certificate
Type: select
__Choices: create, import
Default: create
_Description: Methods for using a X509 certificate to authenticate this host:
It is possible to create a new X509 certificate with user-defined settings
or to import an existing public and private key stored in PEM file(s) for
authenticating IPsec connections.
.
If you choose to create a new X509 certificate you will first be presented
a number of questions which must be answered before the creation can start.
Please keep in mind that if you want the public key to get signed by
an existing certification authority you should not select to create a
self-signed certificate and all the answers given must match exactly the
requirements of the CA, otherwise the certificate request may be rejected.
.
In case you want to import an existing public and private key you will be
prompted for their filenames (may be identical if both parts are stored
together in one file). Optionally you may also specify a filename where the
public key(s) of the certification authority are kept, but this file cannot
be the same as the former ones. Please be also aware that the format for the
X509 certificates has to be PEM and that the private key must not be encrypted
or the import procedure will fail.
Template: openswan/existing_x509_certificate_filename
Type: string
_Description: Please enter the location of your X509 certificate in PEM format:
Please enter the location of the file containing your X509 certificate in
PEM format.
Template: openswan/existing_x509_key_filename
Type: string
_Description: Please enter the location of your X509 private key in PEM format:
Please enter the location of the file containing the private RSA key
matching your X509 certificate in PEM format. This can be the same file
that contains the X509 certificate.
Template: openswan/existing_x509_rootca_filename
Type: string
_Description: You may now enter the location of your X509 RootCA in PEM format:
Optionally you can now enter the location of the file containing the X509
certificate authority root used to sign your certificate in PEM format. If you
do not have one or do not want to use it please leave the field empty. Please
note that it's not possible to store the RootCA in the same file as your X509
certificate or private key.
Template: openswan/rsa_key_length
Type: string
Default: 2048
_Description: Please enter which length the created RSA key should have:
Please enter the length of the created RSA key. it should not be less than
1024 bits because this should be considered unsecure and you will probably
not need anything more than 4096 bits because it only slows the
authentication process down and is not needed at the moment.
Template: openswan/x509_self_signed
Type: boolean
Default: true
_Description: Do you want to create a self-signed X509 certificate?
This installer can only create self-signed X509 certificates
automatically, because otherwise a certificate authority is needed to sign
the certificate request. If you want to create a self-signed certificate,
you can use it immediately to connect to other IPsec hosts that support
X509 certificate for authentication of IPsec connections. However, if you
want to use the new PKI features of Openswan >= 1.91, you will need to
have all X509 certificates signed by a single certificate authority to
create a trust path.
.
If you do not want to create a self-signed certificate, then this
installer will only create the RSA private key and the certificate request
and you will have to sign the certificate request with your certificate
authority.
Template: openswan/x509_country_code
Type: string
Default: AT
_Description: Please enter the country code for the X509 certificate request:
Please enter the 2 letter country code for your country. This code will be
placed in the certificate request.
.
You really need to enter a valid country code here, because openssl will
refuse to generate certificates without one. An empty field is allowed for
any other field of the X.509 certificate, but not for this one.
.
Example: AT
Template: openswan/x509_state_name
Type: string
Default:
_Description: Please enter the state or province name for the X509 certificate request:
Please enter the full name of the state or province you live in. This name
will be placed in the certificate request.
.
Example: Upper Austria
Template: openswan/x509_locality_name
Type: string
Default:
_Description: Please enter the locality name for the X509 certificate request:
Please enter the locality (e.g. city) where you live. This name will be
placed in the certificate request.
.
Example: Vienna
Template: openswan/x509_organization_name
Type: string
Default:
_Description: Please enter the organization name for the X509 certificate request:
Please enter the organization (e.g. company) that the X509 certificate
should be created for. This name will be placed in the certificate
request.
.
Example: Debian
Template: openswan/x509_organizational_unit
Type: string
Default:
_Description: Please enter the organizational unit for the X509 certificate request:
Please enter the organizational unit (e.g. section) that the X509
certificate should be created for. This name will be placed in the
certificate request.
.
Example: security group
Template: openswan/x509_common_name
Type: string
Default:
_Description: Please enter the common name for the X509 certificate request:
Please enter the common name (e.g. the host name of this machine) for
which the X509 certificate should be created for. This name will be placed
in the certificate request.
.
Example: gateway.debian.org
Template: openswan/x509_email_address
Type: string
Default:
_Description: Please enter the email address for the X509 certificate request:
Please enter the email address of the person or organization who is
responsible for the X509 certificate, This address will be placed in the
certificate request.
Template: openswan/no-oe_include_file
Type: note
_Description: Modification of /etc/ipsec.conf
Due to a change in upstream Openswan, opportunistic encryption is no longer
enabled by default. The no_oe.conf file that was shipped in earlier versions
to explicitly disable it can therefore no longer be included by ipsec.conf.
A respective include paragraph will now be automatically removed to ensure
that Openswan can start correctly.
Reply to: