[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <51E7B145.6010601@redhat.com>
Date: Thu, 18 Jul 2013 03:11:33 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: mancha <mancha1@...h.com>
Subject: Re: CVE Request - xlockmore 5.43 fixes a security
flaw
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/16/2013 03:17 PM, mancha wrote:
> On Tue, 16 Jul 2013 20:18:06 +0000 "Kurt Seifried" wrote:
>> To reiterate: so I can confirm CVE assignments, and prevent
>> duplicate assignments you *MUST* provide links to the code
>> commits/vulnerable code.
>
>> People need to start making better CVE requests, or you're not
>> going to get CVEs from me.
>
> I am relatively new at CVE requests so I am learning-by-doing. I
> must have missed the original comment you feel you're re-iterating
> to me.
>
> Relevant code can be found here:
>
> [1]
> http://sourceforge.net/projects/miscellaneouspa/files/glibc217/xlock
>
>
more-5.42-glibc217-crypt.diff
Thanks, Please use CVE-2013-4143 for this issue.
> Upstream doesn't appear to have a public version control repo which
> is why I didn't post link(s) to commit(s). I mistakenly thought
> their changelog annoucement would be enough.
Huh? So just the release tarballs? That's annoying :P As for the
requirements it depends, different CVE requesters have different
requirements depending on how well they do things. E.g. Some do CVE
very well, but to make absolutely sure SPLIT/MERGE is done right I
request some details, others like Drupal have security advisories that
are sufficiently detailed that i can assign based on them alone, so
until a CVE requester proves that they know what they are doing,
reliably, I'm going to need details to make sure the CVE assignment is
done correctly. Part of the issue is scale, I do 1000+ CVE assignments
a year, so if they start taking more then 5-10 minutes I won't have
time to do anything else (like my day job, or sleep).
> I enjoy contributing time to the community via code submissions and
> by making flaws/fixes known to vendors via this list. I just hope
> they don't all have to raise my blood pressure in the future.
Welcome to security where just contacting some of them can be an epic
task.
> --mancha
>
- --
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.13 (GNU/Linux)
iQIcBAEBAgAGBQJR57FEAAoJEBYNRVNeJnmTVLIQAIv1cnjsVFTJe1AnD430MddW
CqnynTT/YXB9/Q4P7ygcQn9wql6uj3Bp60nhR39EU3ZCBMJPpIQC5zJrYTD+whsG
wABnp5XNNAKgvvzpuQYsu7Bn/eGWEaCjwKSwinwh7ZKwOWKyekl9M8F2rOnzbsQm
h2b/MwAQ2x88HCl6bhTdrcKfDM+AKRUwVXB0mb4n+I6xOh1Lw4ADLDXFxdpPGisD
Wi/aOZkvbVDFoO+sh4WjfJNbSna7RCy5d9yvolSTIs82R51Gng/MaXa0opMy1A7v
nH3oA22iMWD3nNVRDhH6qFJOwJ1iqi112/BP9GBF1Xr3n2GfpLctDsRozEbzw+77
FK64F7xSw15/msH0frnPVq/s3ryIL5l5caauGYuu8s/NXPvYqm4VPW7OKnP9KORs
V/jYgVFWea8wNz+7HZutbanipyKGilfMyJLx0fiVxhwRzQ77+a+RYVjMjpMleFZe
ZyVWSAl3lk54Gaz+puFnNc161fdUYg69LSw4IgRVJ05WfDee3OYXYjNaE2Vdvqoz
0LNkY2aYoBdrrgmVJb13ItTz2smv5yxVdMv2pBrRGHNqQGK4SZa6ogXhW/dqECLn
oIMm7R5gJFFIvn0UK7ZYu9+xkaZXeTgRHZ9rqg8SoeavMPUCoaO6geUIx46l3CgE
s6+MGioxUjdc020Z6drg
=ZSyP
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
