Hi all, Where can I find Centos Security Advisory database? The one that I believe similar with RHSA? 2ndly, is there any script available to check if there's any CESA against my installed Centos? Thank you very much.
On 02/07/2010 04:50, Fajar Priyanto wrote:
Hi all, Where can I find Centos Security Advisory database? The one that I believe similar with RHSA? 2ndly, is there any script available to check if there's any CESA against my installed Centos? Thank you very much.
Not at the moment, afaik. But its something that I'm working on at the moment. It all ties into the fasttrack repo and how the background metadata is handled. hope to have some news on this front in the next few weeks.
- KB
On 02/07/2010 04:50, Fajar Priyanto wrote:
Hi all, Where can I find Centos Security Advisory database? The one that I believe similar with RHSA? 2ndly, is there any script available to check if there's any CESA against my installed Centos? Thank you very much.
Not at the moment, afaik. But its something that I'm working on at the moment. It all ties into the fasttrack repo and how the background metadata is handled. hope to have some news on this front in the next few weeks.
- KB
Hello Karan,
with other words you are working on making the yum-security plugin usable on CentOS? That would be great!
Regards
Alexander
http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/
Hi Alexander,
On 02/07/2010 13:49, Alexander Dalloz wrote:
with other words you are working on making the yum-security plugin usable on CentOS? That would be great!
Thats where this whole thing started from. The problem is that the yum-security plugin needs some specific info available in the CentOS repo's and the place where its generated has licensing issues with us just using it as is.
So the thinking is that if there is a generic backend info pool of all this information, changelog, package payload, package headers, metadata around the packages, their relationships with each other and then amalgamate that into an ( hopefully ) easy to use backend, we can then write multiple frontends - each with its own utility.
Ideally I'd like to just work on the backend and release a generic api around it using rest/json for everyone to scratch their own itch :)
Spent a few hours working on this over the weekend and feeling quite confident that there should be something usable soon.
- KB
On Tue, Jul 6, 2010 at 4:12 AM, Karanbir Singh mail-lists@karan.org wrote:
Thats where this whole thing started from. The problem is that the yum-security plugin needs some specific info available in the CentOS repo's and the place where its generated has licensing issues with us just using it as is.
So the thinking is that if there is a generic backend info pool of all this information, changelog, package payload, package headers, metadata around the packages, their relationships with each other and then amalgamate that into an ( hopefully ) easy to use backend, we can then write multiple frontends - each with its own utility.
Ideally I'd like to just work on the backend and release a generic api around it using rest/json for everyone to scratch their own itch :)
Spent a few hours working on this over the weekend and feeling quite confident that there should be something usable soon.
Hi Karan, Any good news yet? ^^
Hi,
On 07/26/2010 09:20 AM, Fajar Priyanto wrote:
Spent a few hours working on this over the weekend and feeling quite confident that there should be something usable soon.
Hi Karan, Any good news yet? ^^
Not yet. I've had to refocus a bit on a few things and this got pushed back by a couple of weeks
- KB
Karanbir Singh wrote, On 07/05/2010 04:12 PM:
Hi Alexander,
On 02/07/2010 13:49, Alexander Dalloz wrote:
with other words you are working on making the yum-security plugin usable on CentOS? That would be great!
Thats where this whole thing started from. The problem is that the yum-security plugin needs some specific info available in the CentOS repo's and the place where its generated has licensing issues with us just using it as is.
Am I being overly optimistic here, in hoping the portions the 'place where its generated has licensing issues' is just with copying verbatim the collated data from their database (CVEs & bugs fields) and the written prose (Description field)?
would they be OK with those fields being done like the announce messages, i.e. just point to the URL for the info, not replicate it? That is, at least for an early usable version set title :announce msg subject info post the CESA-number Update ID: CESA-from announce message Issued : when did the announce msg get generated? Type : as appropriate, and known from message Bugs & CVEs: see URL, yes or empty (unless fills a CentOS tracker item too). Description : Upstream details URL from announce msg. Files: Well, what did the build from SRPM produce for this arch?
Over all at least have it so yum update-minimal would work, and full details elsewhere?
-
Alexander Dalloz -
Fajar Priyanto -
Karanbir Singh -
Todd Denniston