Re: Scalable Debian vulnerability tracking [REDUX]
http://debianhelpdesk.com/sysinfo.tgz md5sum 0704c3016a64817f1d2dcee7af3b3fa1 This is not production ready. It is currently in production, but only on my clients sites, and I fix things as they pop up. As I say in the README, we're working on a major rewrite that should make it much more usable to others (one of the goals). Feel free to contact me with any questions and/or comments. I take constructive criticism very, very well, and would really like it if anyone could use this at all. I will likely not have the new version production ready for a couple of months. Paying gigs keep getting in the way. Rod R. W. Rodolico wrote: Give me a couple of days to find a version that is not totally unstable. I'll tar it up, get some brief explanation, and post the URL here. Right now, the best 1.x stuff is wrapped up in a .deb. I have 2.0b in testing (on a few machines), but it is showing some bugs. I don't trust my svn install (haven't tested to see if I set it up correctly). I did not make myself clear. The UI to view the summaries and reports is written in PHP. The engines (the client side data gatherer and the server side parser) are all perl. I don't think I've ever written a command line PHP script yet. The big difference between v1 and v2 is that I've gone to xml for the report from the client to the server, and the UI is being broken up into modules so people can add/remove more easily (should have done that from the beginning). In most cases, I do not consider e-mail to be unreliable. However, there are some cases where e-mail is less than optimum. So, I plan to allow https and ftp in the future. Rod Holger Levsen wrote: Hi Sheldon, this sounds like an interesting project, please keep us posted! On Mittwoch, 7. Januar 2009, Sheldon Hearn wrote: On Wednesday 07 January 2009 00:24:09 R. W. Rodolico wrote: I have a package that we have been working on for a while that might be a good starting point. This is gpl'd, and I would be happy to supply the .deb, the source tree or svn access if you would like to look at it. Suppressing my knee-jerk reaction to PHP, it sounds like you're quite far down the track with this one. :-) sitesummary, as in http://packages.qa.debian.org/s/sitesummary.html might also be interested for you to look at. and it's perl, not php. On a site note, I dont consider mail to be too unreliable here. First, it's actually pretty reliable. Second, just resend the mail the next day / time slot. regards, Holger -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Scalable Debian vulnerability tracking [REDUX]
Hi Sheldon, this sounds like an interesting project, please keep us posted! On Mittwoch, 7. Januar 2009, Sheldon Hearn wrote: On Wednesday 07 January 2009 00:24:09 R. W. Rodolico wrote: I have a package that we have been working on for a while that might be a good starting point. This is gpl'd, and I would be happy to supply the .deb, the source tree or svn access if you would like to look at it. Suppressing my knee-jerk reaction to PHP, it sounds like you're quite far down the track with this one. :-) sitesummary, as in http://packages.qa.debian.org/s/sitesummary.html might also be interested for you to look at. and it's perl, not php. On a site note, I dont consider mail to be too unreliable here. First, it's actually pretty reliable. Second, just resend the mail the next day / time slot. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Scalable Debian vulnerability tracking [REDUX]
Give me a couple of days to find a version that is not totally unstable. I'll tar it up, get some brief explanation, and post the URL here. Right now, the best 1.x stuff is wrapped up in a .deb. I have 2.0b in testing (on a few machines), but it is showing some bugs. I don't trust my svn install (haven't tested to see if I set it up correctly). I did not make myself clear. The UI to view the summaries and reports is written in PHP. The engines (the client side data gatherer and the server side parser) are all perl. I don't think I've ever written a command line PHP script yet. The big difference between v1 and v2 is that I've gone to xml for the report from the client to the server, and the UI is being broken up into modules so people can add/remove more easily (should have done that from the beginning). In most cases, I do not consider e-mail to be unreliable. However, there are some cases where e-mail is less than optimum. So, I plan to allow https and ftp in the future. Rod Holger Levsen wrote: Hi Sheldon, this sounds like an interesting project, please keep us posted! On Mittwoch, 7. Januar 2009, Sheldon Hearn wrote: On Wednesday 07 January 2009 00:24:09 R. W. Rodolico wrote: I have a package that we have been working on for a while that might be a good starting point. This is gpl'd, and I would be happy to supply the .deb, the source tree or svn access if you would like to look at it. Suppressing my knee-jerk reaction to PHP, it sounds like you're quite far down the track with this one. :-) sitesummary, as in http://packages.qa.debian.org/s/sitesummary.html might also be interested for you to look at. and it's perl, not php. On a site note, I dont consider mail to be too unreliable here. First, it's actually pretty reliable. Second, just resend the mail the next day / time slot. regards, Holger -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Scalable Debian vulnerability tracking [REDUX]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 06 January 2009 23:28:29 Erik Harrison wrote: actually, if you do find something that does this, dont publish anything. start a company. No thanks. Just got out of that game and am thoroughly enjoying being an employee in an organisation that recognizes the value of open source and encourages contribution. :-) On Wednesday 07 January 2009 06:39:53 Luis Mondesi wrote: Is there anything wrong with using cfengine for this? Nothing wrong with that. In fact, we'll be using Puppet instead. But yes, it would certainly be better to just keep up to date with updates in a near-fully automated fashion. But we won't be done with that this quarter, and for some time after we're done, we'll still want to monitor that we're getting it right. On Wednesday 07 January 2009 02:44:46 Jonas Andradas wrote: If you can modify the mail system of each host, you could create an exim4 router and transport that will accept mail for a local user (lets call it SecMonitor) which would pipe the output of debsecan to a script (be it shell, perl, python or anything you choose). Interesting. I hadn't considered letting debsecan do the work but obviating SMTP as the transport protocol. I'll have a think about whether I like the idea of leaving the work of the vulnerability resolver up to the client hosts. It opens the door for decentralized local policy configuration, which is good and bad. :-) On Wednesday 07 January 2009 00:24:09 R. W. Rodolico wrote: I have a package that we have been working on for a while that might be a good starting point. This is gpl'd, and I would be happy to supply the .deb, the source tree or svn access if you would like to look at it. Suppressing my knee-jerk reaction to PHP, it sounds like you're quite far down the track with this one. :-) I'd love to see what you've got, and from the sound of it, at least one other person on this list would like to see it too. SVN access would be first prize, but a source tarball might be easier for you to arrange if you elect to disclose a URL here. On Wednesday 07 January 2009 01:45:36 Moritz Muehlenhoff wrote: We have an extensive HOWTO on how the Debian Security Tracker works: http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction? op=filerev=0sc=0 This is gold, thank you. Is there also an explanation of the file format of the debsecan feeds, though? By debsecan feeds, I mean the libz-compressed files such as http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/etch In particular, I'm still unclear on how to interpret the unstable_version and other_versions fields. Thanks, Sheldon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJZFLGpGJX8XSgas0RAjhIAKCTqiJZUvzcm2IJUxHNJft8Mn87WwCdHspz i2Kn6xSM2EHJSjHYGZ+HI5I= =FMK9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
