Re: Re: CVE-2013-2073 transifex-client: Does not validate HTTPS server certificate (fixed in transifex-client v0.9)

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/16/2013 02:10 AM, Tomas Hoger wrote:
> On Sun, 15 Dec 2013 15:19:54 -0500 (EST) cve-assign () mitre org
> wrote:
>
> > > The way certificate check was implemented to fix CVE-2013-2073
> > > was incorrect (check was done on "probe" connection, but not
> > > the actual connection used to transfer data).
> >
> > To have two CVEs assigned in response to two different patches
> > for the same security problem, it's generally necessary for the
> > first patch to fix some aspect of the problem. If the first patch
> > accomplished nothing, a total of only one CVE is used.
>
> That's not consistent with guidance I've seen in the past - if
> update is released claiming to fix some issue without actually
> fixing it, new CVE is needed.  Not doing so leads to inconsistent
> security update data with two different updates or package versions
> of the same component being listed as fixing the same CVE.  Release
> text can probably explain id reuse, and consider it sufficient for
> human consumption, but it's probably more upsetting to tools
> processing machine readable versions of update notifications (e.g.
> OVAL).

If there was a patch to try and fix it, then a release, then a new
patch to fix it for real and a new release  that would definitely get
a new CVE. If there was a patch, then a new patch, but no official
release in between it's a grey area.


- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBAgAGBQJSr7CPAAoJEBYNRVNeJnmTIBAP/jhRFbUgxulS42chjgGgftwA
ZY+QF0ElJTCKtOXXiAdb4XQNIxG30UGV9IFXjWzk6+OI0wDe8HfbZKc+h0mV1Bf0
B6xCic9E3S2JjH1jnrwIpMAyzyFzTsA6UfbtqbRe5hYqaWP7Rn+VvtvcEGNO27iS
3yOfYpSCNAZvXqAgL4TmO1Z+frXQNXylaLf6OxRGi6td/yGL/F4sJsbjJRDO3xwA
j8r92bVTqZVYdtFLyLJL/VQYxDnj+n9PAdgCceCs23sahbu5sAt/1pmjGUUJcgaz
LmMLJdhbU3Z1Fd7OtDd9d7cp/5l8pRCEE9ldO8aKdoFegKnmNWe959Al/Pgu93t6
nvAnm9NshmPSn8cKQkuKkyER1SvWUDfZlv+TrRHM7sahucNIYWSsRVvrdVmBnwvM
RLkyY18541k5MnVLnwIW0cJCLtQrRgsAUNXMvkmMJ2YXV53EVJdyQz7N9VQJousJ
xLow3+Vlb3oUdud1wmhDc/Y5vaXiNpcXG+qPeJuiIgNHl4Mf9/Q4yU1eTgfALLIC
C+Rqm/HbG6s9bpk3MJ57bFBvAWoTM/2TJnv2l6qNpJWMf/j6Y/D5o2SFwEaTUCq6
6uxa4wog+PXBTcT3s7pHkMDxo3eGXgqgCU5PwbBznm2cmFS2Etzs5SqAmFwtYldh
RbZlQLnZArxSrItpZYVZ
=IGxK
-----END PGP SIGNATURE-----