Re: libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Ola Lundqvist]

Hi

Yes I forgot to push my changes. Thanks for handling it for me.

// Ola

On 12 April 2018 at 14:14, Ola Lundqvist  wrote:

> Hi
>
> I thought I did. Maybe I forgot to push my changes.
>
> Thanks for resolving it.
>
> // Ola
>
> On 11 April 2018 at 22:18, Antoine Beaupré 
> wrote:
>
>> On 2018-04-10 14:33:28, Ola Lundqvist wrote:
>> > Hi Salvatore
>> >
>> > Great. Thanks. Then we do not need to do anything more to libgcrypt.
>> I'll
>> > remove it from dla-needed.txt.
>>
>> Assuming you forgot to do so, I went ahead and removed it from
>> dla-needed.txt and marked it as no-dsa in wheezy.
>>
>> A.
>>
>> --
>> Arguing for surveillance because you have nothing to hide is no
>> different than making the claim, "I don't care about freedom of speech
>> because I have nothing to say."
>> - Edward Snowden
>>
>
>
>
> --
>  --- Inguza Technology AB --- MSc in Information Technology 
> /  o...@inguza.comFolkebogatan 26\
> |  o...@debian.org   654 68 KARLSTAD|
> |  http://inguza.com/Mobile: +46 (0)70-332 1551 |
> \  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
>  ---
>
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Ola Lundqvist]

Hi

I thought I did. Maybe I forgot to push my changes.

Thanks for resolving it.

// Ola

On 11 April 2018 at 22:18, Antoine Beaupré  wrote:

> On 2018-04-10 14:33:28, Ola Lundqvist wrote:
> > Hi Salvatore
> >
> > Great. Thanks. Then we do not need to do anything more to libgcrypt. I'll
> > remove it from dla-needed.txt.
>
> Assuming you forgot to do so, I went ahead and removed it from
> dla-needed.txt and marked it as no-dsa in wheezy.
>
> A.
>
> --
> Arguing for surveillance because you have nothing to hide is no
> different than making the claim, "I don't care about freedom of speech
> because I have nothing to say."
> - Edward Snowden
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Antoine Beaupré]

On 2018-04-10 14:33:28, Ola Lundqvist wrote:
> Hi Salvatore
>
> Great. Thanks. Then we do not need to do anything more to libgcrypt. I'll
> remove it from dla-needed.txt.

Assuming you forgot to do so, I went ahead and removed it from
dla-needed.txt and marked it as no-dsa in wheezy.

A.

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Re: libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Ola Lundqvist]

Hi Salvatore

Great. Thanks. Then we do not need to do anything more to libgcrypt. I'll
remove it from dla-needed.txt.

// Ola

On 9 April 2018 at 21:06, Salvatore Bonaccorso  wrote:

> Hi Ola,
>
> On Mon, Apr 09, 2018 at 08:59:32PM +0200, Ola Lundqvist wrote:
> > Hi all
> >
> > I found another issue that looks very similar. It is
> > https://security-tracker.debian.org/tracker/CVE-2018-6594
> >
> > Should we treat it the same way, marking it as ignored?
>
> I guess you mean CVE-2018-6829?
>
> If so this has already been marked unimportant with an explanation why
> we think so in the notes.
>
> Regards,
> Salvatore
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Salvatore Bonaccorso]

Hi Ola,

On Mon, Apr 09, 2018 at 08:59:32PM +0200, Ola Lundqvist wrote:
> Hi all
> 
> I found another issue that looks very similar. It is
> https://security-tracker.debian.org/tracker/CVE-2018-6594
> 
> Should we treat it the same way, marking it as ignored?

I guess you mean CVE-2018-6829?

If so this has already been marked unimportant with an explanation why
we think so in the notes.

Regards,
Salvatore

libgcrypt11 same issue? Was: Re: [SECURITY] [DLA 1283-1] python-crypto security update

[Ola Lundqvist]

Hi all

I found another issue that looks very similar. It is
https://security-tracker.debian.org/tracker/CVE-2018-6594

Should we treat it the same way, marking it as ignored?

Best regards

// Ola

On 9 April 2018 at 07:26, Salvatore Bonaccorso  wrote:

> Hi Brian,
>
> On Fri, Apr 06, 2018 at 07:06:30PM +1000, Brian May wrote:
> > Ola Lundqvist  writes:
> >
> > > This is what I think we should do.
> > >
> > > 1) Send a new DLA telling that the fix is only partial and not
> complete and
> > > in addtion that elgamal encryption is not supported by the library and
> > > should not be used.
> > >
> > > 2) Mark the CVE as no-dsa/ignored in the security database.
> >
> > If so, do we update the DLA 1283-1 to remove the fixed status? I assume
> > we just have to update the entry in security-tracker/data/DLA/list?
>
> Yes if that what you want to do, to remove the fixed status, just
> remove the CVE entry from the DLA-1283-1 block in data/DLA/list.
>
> At same time remove as well the cross-reference to DLA-1283-1 in
> data/CVE/list, which OTOH otherwise will be dropped on next automatic
> run.
>
> Regards,
> Salvatore
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

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

[Salvatore Bonaccorso]

Hi Brian,

On Fri, Apr 06, 2018 at 07:06:30PM +1000, Brian May wrote:
> Ola Lundqvist  writes:
> 
> > This is what I think we should do.
> >
> > 1) Send a new DLA telling that the fix is only partial and not complete and
> > in addtion that elgamal encryption is not supported by the library and
> > should not be used.
> >
> > 2) Mark the CVE as no-dsa/ignored in the security database.
> 
> If so, do we update the DLA 1283-1 to remove the fixed status? I assume
> we just have to update the entry in security-tracker/data/DLA/list?

Yes if that what you want to do, to remove the fixed status, just
remove the CVE entry from the DLA-1283-1 block in data/DLA/list.

At same time remove as well the cross-reference to DLA-1283-1 in
data/CVE/list, which OTOH otherwise will be dropped on next automatic
run.

Regards,
Salvatore

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

[Ola Lundqvist]

I think this sounds like a good plan.

Sent from a phone

Den fre 6 apr 2018 11:06Brian May  skrev:

> Ola Lundqvist  writes:
>
> > This is what I think we should do.
> >
> > 1) Send a new DLA telling that the fix is only partial and not complete
> and
> > in addtion that elgamal encryption is not supported by the library and
> > should not be used.
> >
> > 2) Mark the CVE as no-dsa/ignored in the security database.
>
> If so, do we update the DLA 1283-1 to remove the fixed status? I assume
> we just have to update the entry in security-tracker/data/DLA/list?
>
> In any case, it seems like a good plan. Unless there are any objections,
> I will do this next Monday.
> --
> Brian May 
>

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

[Brian May]

Ola Lundqvist  writes:

> This is what I think we should do.
>
> 1) Send a new DLA telling that the fix is only partial and not complete and
> in addtion that elgamal encryption is not supported by the library and
> should not be used.
>
> 2) Mark the CVE as no-dsa/ignored in the security database.

If so, do we update the DLA 1283-1 to remove the fixed status? I assume
we just have to update the entry in security-tracker/data/DLA/list?

In any case, it seems like a good plan. Unless there are any objections,
I will do this next Monday.
-- 
Brian May 

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

[Ola Lundqvist]

Hi Brian

This is what I think we should do.

1) Send a new DLA telling that the fix is only partial and not complete and
in addtion that elgamal encryption is not supported by the library and
should not be used.

2) Mark the CVE as no-dsa/ignored in the security database.

Suggested DLA text. Any opinion about this text? I'm not a native English
speaker so my language may not be the best.

Package: python-crypto
Version: 2.6-4+deb7u8
CVE ID : CVE-2018-6594
Debian Bug : 88

This is an update to DLA-1283-1. In DLA-1283-1 it is claimed that the issue
described in CVE-2018-6594 is fixed. It turns out that the fix is partial
and
upstream has decided not to fix the issue as it would break compatibility
and
that ElGamal encryption was not intended to work on its own.

The recommendation is still to upgrade python-crypto packages but in
addition
to that consider that the fix is not complete. If you application using
python-crypto
is implementing ElGamal encryption you should consider changing to some
other encryption method.

There will be no further update to python-crypto for this specific CVE. A
fix would
break compatibility, the problem has been ignored by regular Debian
Security team
due to its minor nature and in addition to that we are close to the end of
life of the
Wheezy security support.

CVE-2018-6594:

python-crypto generated weak ElGamal key parameters, which allowed
attackers to
obtain sensitive information by reading ciphertext data (i.e., it did not
have
semantic security in face of a ciphertext-only attack).

For Debian 7 "Wheezy", the problem has been partially fixed in version
2.6-4+deb7u8.

We recommend that you upgrade your python-crypto packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS


On 3 April 2018 at 00:02, Brian May  wrote:

> Ola Lundqvist  writes:
>
> > Do we have a fix that solve the problem? If we do we can simply upload a
> > new version with the fix and describe it accordingly.
> > If it is fixed in some cases it may be considered fixed.
> >
> > I have not checked the details about this specific problem.
>
> There are no known fixes.
>
> Upstream argues that a fix is unnecessarily, because the key
> vulnerability is only a problem when using the encryption, which is not
> "is not meant to be used by itself". Furthermore they say fixing this
> will break "backward compatibility with PGP".
>
> For full details, read the upstream bug report:
> https://github.com/Legrandin/pycryptodome/issues/90
>
> Or, put another way, upstream renamed the "encrypt" function to
> "_encrypt" a while back to indicate this should not be used. I think it
> really depends on your point of view if this is sufficient to fix a
> security vulnerability in key creation (another function) when used
> directly with encryption.
> --
> Brian May 
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

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

[Brian May]

Ola Lundqvist  writes:

> Do we have a fix that solve the problem? If we do we can simply upload a
> new version with the fix and describe it accordingly.
> If it is fixed in some cases it may be considered fixed.
>
> I have not checked the details about this specific problem.

There are no known fixes.

Upstream argues that a fix is unnecessarily, because the key
vulnerability is only a problem when using the encryption, which is not
"is not meant to be used by itself". Furthermore they say fixing this
will break "backward compatibility with PGP".

For full details, read the upstream bug report:
https://github.com/Legrandin/pycryptodome/issues/90

Or, put another way, upstream renamed the "encrypt" function to
"_encrypt" a while back to indicate this should not be used. I think it
really depends on your point of view if this is sufficient to fix a
security vulnerability in key creation (another function) when used
directly with encryption.
-- 
Brian May 

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

[Ola Lundqvist]

Hi

Do we have a fix that solve the problem? If we do we can simply upload a
new version with the fix and describe it accordingly.
If it is fixed in some cases it may be considered fixed.

I have not checked the details about this specific problem.

// Ola

On 2 April 2018 at 10:22, Brian May  wrote:

> Ola Lundqvist  writes:
>
> > We can simply send a DLA-1283-2 telling that it was not fixed.
>
> Do we all agree that this is not fixed? It really depends on the user's
> of this library and how they use it.
>
> Lets assume we agree it isn't fixed.
>
> I cannot think how to word this advisory. I don't think we have any
> advisory yet that completely reverses an existing advisory. Maybe
> somethin glike "DLA1283-1 indicated that we have a solution for
> CVE-2018-6594, but this has been disputed by the researchers who found
> the problem who claim the problem is not fixed."?
>
> Also we would somehow have to update the security tracker to reflect
> that the issue is not actually fixed.
> --
> Brian May 
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

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

[Brian May]

Ola Lundqvist  writes:

> We can simply send a DLA-1283-2 telling that it was not fixed.

Do we all agree that this is not fixed? It really depends on the user's
of this library and how they use it.

Lets assume we agree it isn't fixed.

I cannot think how to word this advisory. I don't think we have any
advisory yet that completely reverses an existing advisory. Maybe
somethin glike "DLA1283-1 indicated that we have a solution for
CVE-2018-6594, but this has been disputed by the researchers who found
the problem who claim the problem is not fixed."?

Also we would somehow have to update the security tracker to reflect
that the issue is not actually fixed.
-- 
Brian May 

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

[Ola Lundqvist]

Hi

We can simply send a DLA-1283-2 telling that it was not fixed.

// Ola

On 29 March 2018 at 21:34, Antoine Beaupré  wrote:

> On 2018-03-27 07:38:43, Brian May wrote:
> > Antoine Beaupré  writes:
> >
> >> I'm not sure. The security team marked that as "no-dsa (minor issue)"
> >> for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't
> >> we reuse the fixes from cryptodome to get this working properly? Or is
> >> this what you say breaks API compatibility?
> >
> > I don't think I ever said anything about breaking API compatability.
> >
> > Rather the patch that was applied upstream was considered insufficient
> > (by the security researcher) to fix the problem.
> >
> > This is same patch I used for the LTS problem.
> >
> > Upstream was told about the problem:
> > https://github.com/Legrandin/pycryptodome/issues/90#
> issuecomment-362783537
> >
> > "This indicates that, with your latest modification, ElGamal encryption
> > is now secure under the DDH assumption. However, this is not true. As I
> > mentioned in my previous comment, you must encode plaintexts as
> > quadratic residues, too (which is, I guess, what breaks compatibility)."
> >
> > ... but they didn't seem to care:
> > https://github.com/Legrandin/pycryptodome/issues/90#
> issuecomment-362907413
> >
> > "Since the library itself does not support encryption officially, we
> > cannot make claim an implementation using the keys generated by the
> > library is secure or not."
> >
> > So it does look like fixing this properly might break API compatability,
> > but there are no known fixes we can apply.
>
> Hmm... so I guess the core question here is whether we expect our users
> to actually use cryptodome/pycrypto to do ElGamal-based encryption...
>
> I have the same problem trying to tackle the libgcrypt11 pending
> security issue:
>
> https://security-tracker.debian.org/tracker/CVE-2018-6829
>
> My understanding of this issue is that it only affects consumers of the
> library that use ElGamal for encryption, a similar problem than what is
> described here.
>
> I was tempted to mark this as no-dsa, given how little elgamal is
> actually used in the wild. It was also my understanding that GnuPG
> wasn't vulnerable to this specific issue, but I haven't verified this
> deeply and it's been a while since I checked, so I am not exactly sure
> of that specific claim.
>
> CVE-2018-6594 is marked as no-dsa in Jessie/Stretch, for what that's
> worth...
>
> But the problem now is that we issued DLA-1283-1 to claim this was
> fixed, so at least an update on that should be provided to our users so
> we're clear this is *not* fixed. I'm not sure how to do that.
>
> Anyone else has suggestions here?
>
> A.
> --
> Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are, by
> definition, not smart enough to debug it.
> - Brian W. Kernighan
>
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

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

[Antoine Beaupré]

On 2018-03-27 07:38:43, Brian May wrote:
> Antoine Beaupré  writes:
>
>> I'm not sure. The security team marked that as "no-dsa (minor issue)"
>> for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't
>> we reuse the fixes from cryptodome to get this working properly? Or is
>> this what you say breaks API compatibility?
>
> I don't think I ever said anything about breaking API compatability.
>
> Rather the patch that was applied upstream was considered insufficient
> (by the security researcher) to fix the problem.
>
> This is same patch I used for the LTS problem.
>
> Upstream was told about the problem:
> https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362783537
>
> "This indicates that, with your latest modification, ElGamal encryption
> is now secure under the DDH assumption. However, this is not true. As I
> mentioned in my previous comment, you must encode plaintexts as
> quadratic residues, too (which is, I guess, what breaks compatibility)."
>
> ... but they didn't seem to care:
> https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362907413
>
> "Since the library itself does not support encryption officially, we
> cannot make claim an implementation using the keys generated by the
> library is secure or not."
>
> So it does look like fixing this properly might break API compatability,
> but there are no known fixes we can apply.

Hmm... so I guess the core question here is whether we expect our users
to actually use cryptodome/pycrypto to do ElGamal-based encryption...

I have the same problem trying to tackle the libgcrypt11 pending
security issue:

https://security-tracker.debian.org/tracker/CVE-2018-6829

My understanding of this issue is that it only affects consumers of the
library that use ElGamal for encryption, a similar problem than what is
described here.

I was tempted to mark this as no-dsa, given how little elgamal is
actually used in the wild. It was also my understanding that GnuPG
wasn't vulnerable to this specific issue, but I haven't verified this
deeply and it's been a while since I checked, so I am not exactly sure
of that specific claim.

CVE-2018-6594 is marked as no-dsa in Jessie/Stretch, for what that's
worth...

But the problem now is that we issued DLA-1283-1 to claim this was
fixed, so at least an update on that should be provided to our users so
we're clear this is *not* fixed. I'm not sure how to do that.

Anyone else has suggestions here?

A.
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan

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

[Brian May]

Antoine Beaupré  writes:

> I'm not sure. The security team marked that as "no-dsa (minor issue)"
> for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't
> we reuse the fixes from cryptodome to get this working properly? Or is
> this what you say breaks API compatibility?

I don't think I ever said anything about breaking API compatability.

Rather the patch that was applied upstream was considered insufficient
(by the security researcher) to fix the problem.

This is same patch I used for the LTS problem.

Upstream was told about the problem:
https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362783537

"This indicates that, with your latest modification, ElGamal encryption
is now secure under the DDH assumption. However, this is not true. As I
mentioned in my previous comment, you must encode plaintexts as
quadratic residues, too (which is, I guess, what breaks compatibility)."

... but they didn't seem to care:
https://github.com/Legrandin/pycryptodome/issues/90#issuecomment-362907413

"Since the library itself does not support encryption officially, we
cannot make claim an implementation using the keys generated by the
library is secure or not."

So it does look like fixing this properly might break API compatability,
but there are no known fixes we can apply.
-- 
Brian May 

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

[Antoine Beaupré]

On 2018-02-20 07:33:27, Brian May wrote:
> Any comments? Where should we go from here?

I'm not sure. The security team marked that as "no-dsa (minor issue)"
for jessie and stretch, and fixed in pycryptodome 3.4.11-1... Couldn't
we reuse the fixes from cryptodome to get this working properly? Or is
this what you say breaks API compatibility?

Maybe we just let this one slide? It's not as if ElGamal was a very
popular algo, is it?

a.

-- 
Au nom de l'état, la force s'appelle droit.
Au main de l'individu, elle s'appelle crime.
- Max Stirner

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

[Brian May]

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 

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

[Brian May]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: python-crypto
Version: 2.6-4+deb7u8
CVE ID : CVE-2018-6594
Debian Bug : 88


python-crypto generated weak ElGamal key parameters, which allowed attackers to
obtain sensitive information by reading ciphertext data (i.e., it did not have
semantic security in face of a ciphertext-only attack).

For Debian 7 "Wheezy", these problems have been fixed in version
2.6-4+deb7u8.

We recommend that you upgrade your python-crypto packages.

Further information about Debian LTS security advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://wiki.debian.org/LTS
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE1jZRJqkttWDGJ6ztF4RXf4EfbqwFAlqFOA4ACgkQF4RXf4Ef
bqymzg/+KGjsW0pGUiYyS1EfUDuLhi2vo+qu3REDOrmuP5nTlgmAgUFn3J5EL6ac
klJ7T3NtzM+JJvKeAiSK2HNFDfyIiMU6WCblK7TTYobEWW5OECtYujUbQzAZgYkL
nTvecYjlBj1/K+W6WwAxkkEPuQLh2uCIwqt2efNLJ9CH8zW7vBTKiv+zd3g3lJRI
wZEDh9D7xgYEOic+ADnvNaoXAJSgakaMm7j86JqUqZ201agpjbktGDblo6+nkp4G
B4Cfca8LlHnkS0zsnfr9Ea8gXxvdOoAmJb3GSlcxKSAHBswVeUuP1smR5+SkETpQ
dQ5NR3wuNMe3mhdDIumuAUYMs6g45eRgSMCR79pj4DA7/UycwJIb4FO8f8ZYu1kc
UrwouyDOMisOdpEeTzdBxPfFOG2qbBz8r51ZMeeO0ttF0Zgacp4P1jVuQAmSQ74L
k/CV1BuyyQaNor0h6lI9GahygGwo16pmZiW37Lfl7y2B2PV/IQkrBrjEVTsR3YqE
3hVK/ggP4iO/JQ6OK0kBH3lIQffqETZhoutI+2IIYW6KWHaT++LrfwABpTmg1NuZ
qS2EHHRakiIcdxwFMuz/AczI+1G7WtledW2o2gMhjGNgfEmnza+Cr/F9mRI4j/mx
cz0E2KxjRNXqYoy0rYJKVEqz34hvz28yYRZLMu1zht2UzTsWWqA=
=pHfV
-END PGP SIGNATURE-