[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [SECURITY] [DLA 1283-1] python-crypto security update



My information, as communicated by Erik-Oliver Blass via private email
is that this issue was not fixed upstream.

I had assumed when upstream said "I will close this issue, since this
fix is in v3.4.10." in
https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362907413
it was meant that the problem wax fixed by the recent commit:

https://github.com/Legrandin/pycryptodome/commit/99c27a3b9e8a884bbde0e88c63234b669d4398d8

This is the patch I backported to wheezy-security.

However, this commit by itself is insufficient to solve the problem.

https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362783537

Erik-Oliver Blass has said that upstream solved the problem by disabling
some of the functions, e.g. by renaming "encrypt()" to
"_encrypt()". Which is hardly a guarantee that nobody will use this
code.

Looking at the git history, I see the following commit, which adds new
functions which generate errors:

https://github.com/Legrandin/pycryptodome/commit/ab4ed2dcc1de4e96b1d9fcb63f85cdaa92396071

I don't see any sign of the original encrypt method however, not even if
I look at the first git commit:

https://github.com/Legrandin/pycryptodome/commit/a8a47a73d47172ffae4d3a57ee30608e49505311

Regardless, the python-crypto package in wheezy does have the encrypt
method:

    def encrypt(self, plaintext, K):
        return pubkey.encrypt(self, plaintext, K)

Where pubkey.encrypt() appears just to call self._encrypt(plaintext, K)
after doing some type conversions.

Erik-Oliver Blass is unhappy that they didn't try to fix the problem,
which he says is easy to fix.

I don't think I can backport a change that breaks compatibility like
this to wheezy.

Any comments? Where should we go from here?
-- 
Brian May <bam@debian.org>


Reply to: