Bug#904641: Please remove local build options in debian/gbp.conf
Package: apache2 Version: 2.4.33-3 Severity: important Dear maintainer, The Debian package includes a debian/gbp.conf which sets some global options for git-buildpackage. These are very annoying for anyone willing to rebuild the package. Namely, please remove: pristine-tar = True builder = dpkg-buildpackage -i\.git -I.git upstream-branch=upstream debian-branch=master These are typically things that should go in ~/.gbp.conf. Anyone having a correctly configured sbuild + gbp environment will be very much annoyed by this debian/gbp.conf. In my experience, there's no need to ever have a debian/gbp.conf file. For example, the debian-branch thing can be removed if ~/.gbp.conf contains: ignore-branch = True Cheers, Thomas Goirand (zigo)
Bug#904684: ssl-cert: HostName length check is too small
Package: ssl-cert Version: 1.0.39 Severity: normal In the make_snakeoil() funtion, the code gets the FQDN of the system via a call to 'hostname -f'. Then it checks if this the FQDN is longer than 64 characters, and if it is, uses the short hostname. However, a FQDN can be up to 255 octets per RFC 1035, Section 2.3.4: 2.3.4. Size limits Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental. labels 63 octets or less names 255 octets or less TTL positive values of a signed 32 bit number. https://tools.ietf.org/html/rfc1035 https://stackoverflow.com/questions/32290167/ The 64 octet limit is for each sub-component: part1.partb.foo.example.com So the each of "part1", "foo", etc, must less than 64, and the entire FQDN string must be less than 255. But that is not what the script is checking: it is seeing if the entire FQDN string is less than 64--which is about four times too short. -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ssl-cert depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.61 ii openssl1.1.0f-3+deb9u2 ssl-cert recommends no packages. Versions of packages ssl-cert suggests: pn openssl-blacklist -- debconf information excluded
Bug#904686: ssl-cert: RSA keylength is getting a bit short
Package: ssl-cert Version: 1.0.39 Severity: wishlist The current default keylength for the snakeoil cert is 2048 bits. However, these certs could now live for ten years (3650 days), which as I type this could be upto 2028. Various technical bodies are recently that for long-lived secrets, a factoring modulus (i.e., RSA key size) of 3072 bits is recommended: https://www.keylength.com/en/4/ https://www.keylength.com/en/compare/ 2048b should be good until the year 2030, but we're approaching that now: https://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths While most commercial certificate authorities (CAs) give out 2048 bit certficites, those are only valid for 1-2 years (90 days in the case of Let's Encrypt), so the risk is much less in the short term. Can "-newkey rsa:3072" be added to the ssl-cert script for better future proofing? -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ssl-cert depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.61 ii openssl1.1.0f-3+deb9u2 ssl-cert recommends no packages. Versions of packages ssl-cert suggests: pn openssl-blacklist -- debconf information excluded
