Package: release.debian.org
Followup-For: Bug #701817
User: release.debian....@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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to