Re: Bug#834327: jessie-pu: package gnupg2/2.0.26-6+deb8u1
Aurelien Jarno schrieb: > On 2016-08-14 16:00, Salvatore Bonaccorso wrote: >> Package: release.debian.org >> Severity: normal >> Tags: jessie >> User: release.debian@packages.debian.org >> Usertags: pu >> >> Dear SRM >> >> I would like to propose the following hardening to src:gnupg2 which was >> found during the analysis of a vulnerability report to the security team >> and related to >> https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf >> and developed by NIIBE Yutaka. The underlying problem in hardware cannot >> be solved in software (and thus we don't want to issue a DSA for it, and >> give possibly this false impression), and as pointed out by Florian > > I wonder if it would be a good idea to release an announcement without > any software change recommending people to not enable KSM on their > hosts? I think a NEWS file for the kernel would be best? Cheers, Moritz
Processed: Re: Bug#834326: jessie-pu: package gnupg/1.4.18-7+deb8u2
Processing control commands: > retitle -1 jessie-pu: package gnupg/1.4.18-7+deb8u3 Bug #834326 [release.debian.org] jessie-pu: package gnupg/1.4.18-7+deb8u2 Changed Bug title to 'jessie-pu: package gnupg/1.4.18-7+deb8u3' from 'jessie-pu: package gnupg/1.4.18-7+deb8u2'. -- 834326: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834326 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#834326: jessie-pu: package gnupg/1.4.18-7+deb8u2
Control: retitle -1 jessie-pu: package gnupg/1.4.18-7+deb8u3 On Sun, Aug 14, 2016 at 03:58:28PM +0200, Salvatore Bonaccorso wrote: > Package: release.debian.org > Severity: normal > Tags: jessie > User: release.debian@packages.debian.org > Usertags: pu > > Dear SRM > > I would like to propose the following hardening to src:gnupg which was > found during the analysis of a vulnerability report to the security team > and related to > https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf > and developed by NIIBE Yutaka. The underlying problem in hardware cannot > be solved in software (and thus we don't want to issue a DSA for it, and > give possibly this false impression), and as pointed out by Florian > there are some other open questions regarding the paper and the attacks > described there. > > The GnuPG upstream repository contains the testcase to verify the fix, > as > http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=7dcad0d3503ac0d75e09efb16246dd78518986fc > > The fix for gnupg is in experimental in the src:gnupg1 source package > with commits (1.4.20-6+exp5): > > https://anonscm.debian.org/git/pkg-gnupg/gnupg1.git/commit/?h=experimental&id=5ed457210d69f95ea253221e14e6f8a8c8da0a5f > > and migrated now to unstable, with a new upload on 2016-08-13. > > Thanks in advance, This all stil holds, but I have rebased the patch on top of the update via jessie-security. Regards, Salvatore diff -Nru gnupg-1.4.18/debian/changelog gnupg-1.4.18/debian/changelog --- gnupg-1.4.18/debian/changelog 2016-08-17 21:36:04.0 +0200 +++ gnupg-1.4.18/debian/changelog 2016-08-18 07:13:19.0 +0200 @@ -1,3 +1,11 @@ +gnupg (1.4.18-7+deb8u3) jessie; urgency=medium + + * Non-maintainer with maintainers approval. + * gpgv: Tweak default options for extra security + * g10: Fix checking key for signature validation + + -- Salvatore Bonaccorso Thu, 18 Aug 2016 07:13:19 +0200 + gnupg (1.4.18-7+deb8u2) jessie-security; urgency=high * Non-maintainer upload by the Security Team. diff -Nru gnupg-1.4.18/debian/patches/0048-gpgv-Tweak-default-options-for-extra-security.patch gnupg-1.4.18/debian/patches/0048-gpgv-Tweak-default-options-for-extra-security.patch --- gnupg-1.4.18/debian/patches/0048-gpgv-Tweak-default-options-for-extra-security.patch 1970-01-01 01:00:00.0 +0100 +++ gnupg-1.4.18/debian/patches/0048-gpgv-Tweak-default-options-for-extra-security.patch 2016-08-18 07:13:19.0 +0200 @@ -0,0 +1,39 @@ +From cf01cf8b88abb6ed5fea300c28e2a1e6a7c67804 Mon Sep 17 00:00:00 2001 +From: NIIBE Yutaka +Date: Sat, 9 Jul 2016 10:20:02 +0900 +Subject: [PATCH] gpgv: Tweak default options for extra security. + +* g10/gpgv.c (main): Set opt.no_sig _cache, so that it doesn't depend on +cached status. Similarly, set opt.flags.require_cross_cert for backsig +validation for subkey signature. + +-- + +(backport of master +commit e32c575e0f3704e7563048eea6d26844bdfc494b) + +It is common that an organization distributes binary keyrings with +signature cache (Tag 12, Trust Packet) and people use gpgv to validate +signature with such keyrings. In such a use case, it is possible that +the key validation itself is skipped. + +For the purpose of gpgv validation of signatures, we should not depend +on signature cache in keyrings (if any), but we should validate the key +by its self signature for primary key, and back signature for subkey. + +Signed-off-by: NIIBE Yutaka +--- + g10/gpgv.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/g10/gpgv.c b/g10/gpgv.c +@@ -142,6 +142,8 @@ main( int argc, char **argv ) + opt.pgp2_workarounds = 1; + opt.keyserver_options.options|=KEYSERVER_AUTO_KEY_RETRIEVE; + opt.trust_model = TM_ALWAYS; ++opt.no_sig_cache = 1; ++opt.flags.require_cross_cert = 1; + opt.batch = 1; + + opt.homedir = default_homedir (); diff -Nru gnupg-1.4.18/debian/patches/0049-g10-Fix-checking-key-for-signature-validation.patch gnupg-1.4.18/debian/patches/0049-g10-Fix-checking-key-for-signature-validation.patch --- gnupg-1.4.18/debian/patches/0049-g10-Fix-checking-key-for-signature-validation.patch 1970-01-01 01:00:00.0 +0100 +++ gnupg-1.4.18/debian/patches/0049-g10-Fix-checking-key-for-signature-validation.patch 2016-08-18 07:13:19.0 +0200 @@ -0,0 +1,37 @@ +From f474b161f6c8c7a3dc0fb90d25ffceacba1ff117 Mon Sep 17 00:00:00 2001 +From: NIIBE Yutaka +Date: Thu, 4 Aug 2016 16:21:39 +0900 +Subject: [PATCH] g10: Fix checking key for signature validation. + +* g10/sig-check.c (signature_check2): Not only subkey, but also primary +key should have flags.valid=1. + +-- + +(backport of master +commit 6f284e6ed63f514b15fe610f490ffcefc87a2164) + +Signed-off-by: NIIBE Yutaka +--- + g10/sig-check.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/g10/sig-check.c b/g10/sig-check.c +index 6bac630..8dd0373 100644 +--- a/g10/sig-check.c b/g
Re: Porter roll call for Debian Stretch [arm]
* ni...@thykier.net [2016-08-17 22:05]: > * Which architectures are you committing to be an active porter for? > * Please describe recent relevant porter contributions. > * Are you running/using Debian testing or sid on said port(s)? For armel, armhf and arm64, I: * Triage d-i bugs * Test d-i regularly * Fix d-i bugs/issues * Test latest kernels * Enable kernel options * Write and update documentation armel has support for 2 major SoC platorms, Orion and Kirkwood (both use the "marvell" kernel flavour in stretch). I posted a call for help regarding Orion a few months ago. Since then, Roger Shimizu has been very active with Buffafo devices. I fixed a major problem with HP mv2120 devices (#809611). I also brought back installer support for Orion-based QNAP devices a few months ago. Orion devices are quite old now but they are in good shape for stretch. We support a number of Kirkwood devices (mostly NAS) and they generally work well. I don't see any concerns there from a d-i or kernel perspective. armhf: Karsten Merker, Ian Campbell and Vagrant Cascadian have done a great job with d-i support for armhf. I recently enabled some kernel options for 32-bit NVIDIA Tegra and wrote some documentation. arm64: Steve McIntyre has done great work getting UEFI arm64 platforms supported in d-i. I am working on getting some arm64 platforms supported that use u-boot. A new flash-kernel was uploaded recently and there's more to come. I wrote some documentation about running Debian on ARM devices, e.g.: https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1 https://wiki.debian.org/InstallingDebianOn/Seagate/PersonalCloud If you need more evidence, check out the changelogs for debian-installer, flash-kernel, mv2120-utils and linux. I'm a DD. Martin Michlmayr -- Martin Michlmayr http://www.cyrius.com/ signature.asc Description: Digital signature
Re: Porter roll call for Debian Stretch
On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > * If we were to enable -fPIE/-pie by default in GCC-6, should that change >also apply to this port? [0] If -fPIE is the default will -fPIC override it? It will also default to tell the linker to use -pie, but then don't do it when you want to create a shared library? >From what I understand, depending on what the .o file is going to be used for you want different things: - shared library: -fPIC - executable: -fPIC or -fPIE both work, but prefer -fPIE - static library: Same as executables For static libraries we now have a policy to not use -fPIC, should that then get replaced by using -fPIE? Kurt
Re: Porter roll call for Debian Stretch
Martin Michlmayr: > * ni...@thykier.net [2016-08-17 22:05]: >> 2020), please respond with a signed email containing the following >> before Friday, the 9th of September: > > Can you please specify where to respond to? I don't think dozens of > emails to -ports and -devel make any sense. > Ah, sorry I had indeed forgotten to set Reply-To. :) > Maybe debian-release with CC debian- or to you personally and > you'll collect the info? > Please send the replies to debian-release. :) Thanks, ~Niels
Re: Porter roll call for Debian Stretch
* ni...@thykier.net [2016-08-17 22:05]: > 2020), please respond with a signed email containing the following > before Friday, the 9th of September: Can you please specify where to respond to? I don't think dozens of emails to -ports and -devel make any sense. Maybe debian-release with CC debian- or to you personally and you'll collect the info? -- Martin Michlmayr http://www.cyrius.com/
Porter roll call for Debian Stretch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Like last release, we are doing a roll call for porters of all release architectures. If you are an active porter behind one of the [release architectures] for the entire lifetime of Debian Stretch (est. end of 2020), please respond with a signed email containing the following before Friday, the 9th of September: * Which architectures are you committing to be an active porter for? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? * If we were to enable -fPIE/-pie by default in GCC-6, should that change also apply to this port? [0] Feel free to use the following template as your reply: """ Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Stretchj release (est. end of 2020): For , I - test (most|all) packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services (Please describe these) - ... I believe the port ready to have -fPIE/-pie enabled by default. """ Niels, on behalf of the release team [0] Enabling -fPIE/-fpie by default would harden debian systems against certain attacks. See https://lintian.debian.org/tags/hardening-no-pie.html for more details. -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJXtMMHAAoJEAVLu599gGRCArEP/j259ofvIXh0NE5uLqOtA8vu 4J84y6o15rHgg0iUGFwqAhk6GVtbvpxxqgH5vpj90UmUyIe55tHL7mf4NDjbEu9x w12DezTHpyGmmGSNNkQO6MV6FE0JeDjlSUlgBU27RamCQ7uKWCCNMMV48YZ/vtA0 4gj8KZtYxUNY5PEaCyV2WHXvU4sMuetnqZ4JfVDykCWlHV6yDCWMN/crar7XyWll iulUZFn9KlioVlSfQbkhrdJqwwbzXYaYee+GnD6rfVzPCIwpnVfKWoCYS8Zr0wub chmFx8EYAcBQ9OT5okfxZsN5J8kylX2CCDMEX5Ek6o7+4W76+L+V6F0hi1Npb2AH MFE5JLQLZGPs/3ilZSCz9io3u0vG78sLXPrQFbgJpa1E70W+bxohaieENPB0zGmS YBqF0BLM6XoySAURGMv8ohP3nT53PXtPDCU4EMF75bTvJa3QWJRSBC6uRtAY67tp h1bTWaE7Nmrtw9/mK+1oukjm8N7skvl1n0ZGQ+OmhfNcs8ii33fAV+u5zoGrywG5 0kXOfKfbt231/ManvsdGTHBd6Wodhprbo+Nw5tOA6B1R5jsSs0fvizKBRewrwiY7 66LNPtamSyqVapTBZqMEWaxvpfoWOgU8ZA1F9msD+qTHDd6OPCV692DAJbXlHfJe jof1hm/X+SyTZzungBvV =TKl5 -END PGP SIGNATURE-
Re: 8.6 planning
On Sun, 2016-08-07 at 23:04 +0100, Adam D. Barratt wrote: > It's time for another Jessie point release; as wheezy's EOL, we don't > have to worry about trying to fit two in at the same time. Some > possible > dates: > > August 20th/21st - doesn't work for me > > August 27th/28th - public holiday weekend in the UK; doesn't work for > me These don't work for me either. (Also they are probably too close by now.) > September 3rd/4th Might work with some extra planning, but not that well. > September 10th/11th > > September 17th/18th These should be okay for me. Ansgar
