Bug#701817: unblock: botan1.10/1.10.5-1
Package: release.debian.org
Followup-For: Bug #701817
User: release.debian.org@packages.debian.org
Usertags: unblock
Hi,
I know this is a bold move to ask for inclusion of new upstream
release, but I have checked individual patches between 1.10.3 and
1.10.5 and those non-security is only a small cruft which can be (in
my opinion) safely included. So I would like to avoid a confusion of
our users to create 1.10.3 with most of the patches between 1.10.3 and
1.10.5.
In case you will reject this, I will take the SECURITY PATCHES part
and upload it via t-p-u. I would like to avoid it, but I am prepared
to do that.
Apart from full debdiff I am also including these individual patches:
SECURITY PATCHES
check_for_out_of_range_DH_values.patch
[mtnlog] Check for DH inputs out of range, was removed in the pk_op refactoring.
fix_potential_crash_in_AES-NI.patch
[chglog] A potential crash in the AES-NI implementation of the AES-192 key schedule (caused by misaligned loads) has been fixed.
[mtnlog] Avoid a potentially unaligned __m128i load in the AES-NI implementation of the AES-192 key schedule.
fix_side_channel_attack_in_power_mod.patch
[chglog] Avoid a conditional operation in the power mod
implementations on if a nibble of the exponent was zero or
not. This may help protect against certain forms of side
channel attacks.
[mtnlog] Avoid a conditional in the power mod implementations on if
the nibble is zero or not. Likely an attacker would still be
able to tell if it was zero or not, especially for fixed
window where we just multiply by 1, but it can't hurt.
fix_timing_attack_in_montgomery.patch
[chglog] A previously conditional operation in Montgomery
multiplication and squaring is now always performed, removing
a possible timing channel.
[mntlog] Always perform the add/subtract even if the final value would
end up being zero, so our timing does not depend on the
input.
reject_invalid_SRP_values.patch
[chglog] The SRP6 code was checking for invalid values as specified in
RFC 5054, specifically values equal to zero mod p. However
SRP would accept negative A/B values, or ones larger than p,
neit her of which should occur in a normal run of the
protocol. These values are now rejected. Credits to Timothy
Prepscius for pointing out these values are not normally used
and probably signal something fishy.
[mtnlog] In SRP reject values that are negative or larger than p -
this is safe to accept but still likely bogus. And doing two
compares is cheaper than a modular reduction so a win there
as well.
RANDOM CRUFT
clang_parameters.patch
[chglog] Use correct flags for creating a shared library on OS X under
Clang.
[mtnlog] Use correct Darwin/Clang dynamic link flags
[doesn't affect any compiled code]
version_bump.patch
- Just stuff related to version bump (e.g. version numbers and changelog)
[doesn't affect any compiled code]
deleted_obsolete_examples.patch
- Drop obsolete CMS examples
[doesn't affect any compiled code]
VC++2012_incompatibility_fix.patch
[chglog] Fix a compile time incompatability with Visual C++ 2012.
[mtnlog] Attempted fix at compile time incompatability with VC 2012
[some C++ dark magick, but should not affect anything]
make_version_string_fixed.patch
[chglog] The return value of version_string is now a compile time
constant string, so version information can be more easily
extracted from binaries.
[mtnlog] Make the result of version_string a compile time constant
string, so we can find the complete value by running strings
on a binary file.
[mtnlog] Handle gcc -dumpversion producing only two numbers. Bug 215.
[looks harmless to me]
unblock botan1.10/1.10.5-1
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Reply to: