Hi all As we all know, the DTSA announcements to the testing-security-announce lists are not send anymore. There was the idea of adding a script, which publishes the DTSA in a weekly newsletter (or monthly, or $whatever). Debian-Edu/Skolelinux has some sort of monthly newsletter to add the DSAs concerning the packages used by Debian-Edu/Skolelinux to a list. The announcement email looks like this[0]. On the other hand, I was wondering, why we stopped sending DTSA announcements. Looking at the DTSA list lately, there are not that many DTSAs and if there is a script, which adds the md5sum to the package and has some sort of general template, then it should not take that long to prepare the DTSA announcement, sign and send it to the list (or maybe I am wrong). I would volunteer to take care of the announcements, if it produces too much workload, though it would be nice to have some sort of script to add the md5sum size (this might take a while by hand for packages producing a lot of binary packages). It would maybe also be interesting to know, how many people are subscribed to the testing-security-announce ml. Just my two cents. Cheers Steffen [0]: http://lists.debian.org/debian-edu/2007/08/msg00063.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070821/8f5efc0d/attachment.pgp
Steffen Joeris wrote:> Hi allHi> As we all know, the DTSA announcements to the testing-security-announce lists > are not send anymore. There was the idea of adding a script, which publishes > the DTSA in a weekly newsletter (or monthly, or $whatever).Why are the DTSA announcements not sent anymore?> producing a lot of binary packages). It would maybe also be interesting to > know, how many people are subscribed to the testing-security-announce ml.You might want to contact the listmasters to get that number... Cheers Luk
Hi, * Steffen Joeris <steffen.joeris at skolelinux.de> [2007-08-21 13:58]:> As we all know, the DTSA announcements to the testing-security-announce lists > are not send anymore. There was the idea of adding a script, which publishes > the DTSA in a weekly newsletter (or monthly, or $whatever). > Debian-Edu/Skolelinux has some sort of monthly newsletter to add the DSAs > concerning the packages used by Debian-Edu/Skolelinux to a list. The > announcement email looks like this[0].I don''t really support the idea since I think it would be more usefull for a possible vulnerable user to get this information as fast as it''s available. Having them working again would be nice though :) Kind regards Nico -- Nico Golde - http://ngolde.de - nion at jabber.ccc.de - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070821/c0e5d72a/attachment.pgp
Steffen Joeris wrote:> On the other hand, I was wondering, > why we stopped sending DTSA announcements.Because it singles out a couple of packages, while you need to update daily anyway. The majority of all testing fixes are coming through regular testing migration. IMO a weekly overview like the SuSE security summaries provide the best balance. For up-to-date security overview debsecan is available. Cheers, Moritz
Moritz Muehlenhoff wrote:> Steffen Joeris wrote: >> On the other hand, I was wondering, >> why we stopped sending DTSA announcements. > > Because it singles out a couple of packages, while you need to update daily > anyway. The majority of all testing fixes are coming through regular > testing migration.The problem with not sending DTSAs for testing-security is that some people only want to cherry pick packages from testing-security besides daily upgrading testing...> IMO a weekly overview like the SuSE security summaries provide the best > balance. For up-to-date security overview debsecan is available.A weekly security summary might indeed also be a good idea. debsecan needs at least python (besides a MTA when mail is wanted) which is not always wanted... it''s also host based which has some advantages, but also some disadvantages... Cheers Luk
Hi, on Tuesday 21 August 2007, Steffen Joeris wrote:> As we all know, the DTSA announcements to the > testing-security-announce lists are not send anymore. There was the > idea of adding a script, which publishes the DTSA in a weekly > newsletter (or monthly, or $whatever).As Moritz pointed out, the announcements are of limited value because the user needs the normal testing upgrades as well. What would be nice would be a weekly overview mail that lists all testing-security uploads and all the security fixes that migrated from unstable. If such mails were created automatically, we could also have daily mails on a separate list for people who want to be informed more quickly. But the main reason why I stopped sending the mails was that I lacked time. If someone else wants to send them, that''s fine with me. The current procedure is described in website/index.html and doc/howto-DTSA in the svn repo. Some things could be more automated, but I guess the time would be better spent implementing the weekly summaries.> if there is a script, which adds the md5sum to the packageBTW, we have not sent md5sums in the past and it does not really make sense, because people have to use apt anyway to get the other updates and secure-apt takes care of the integrity checking.> It would maybe also be interesting to know, how many people are > subscribed to the testing-security-announce ml.Currently around 780. Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070821/ca0a7f4e/attachment.pgp
* Luk Claes:> debsecan needs at least python (besides a MTA when mail is wanted) which > is not always wanted... it''s also host based which has some advantages, > but also some disadvantages...Technically, you aren''t forced to run debsecan on the host that''s being analyzed. You can copy /var/lib/dpkg/status and run debsecan on it on another box. But I don''t think anyone is doing it in some form of automated process, and there are likely a few debsecan features which would have to be implemented before this becomes feasible.
3ROn Tue, Aug 21, 2007 at 06:09:56PM +0200, Luk Claes wrote:> Moritz Muehlenhoff wrote: > > Steffen Joeris wrote: > >> On the other hand, I was wondering, > >> why we stopped sending DTSA announcements. > > > > Because it singles out a couple of packages, while you need to update daily > > anyway. The majority of all testing fixes are coming through regular > > testing migration. > > The problem with not sending DTSAs for testing-security is that some > people only want to cherry pick packages from testing-security besides > daily upgrading testing...That''s exactly the problem. In contrast to stable, where all relevant security fixes are coming through stable-security, only a minor subset of testing security fixes are coming through testing-security. So, if there''s only a dedicated annoucement list people will pick these and don''t notice the ones, which have propagated normally. That''s why I recommend an automated summary mail listing all testing-security fixes and the newly propagated security fixes from unstable. (Which might just as well be sent daily, I don''t care about the frequency). Cheers, Moritz
Hi, I wrote some scripts to determine which issues are fixed by migration, DTSA, or removal from testing. Issues that are "fixed" by downgrading to unimportant or not-affected are not included. Currently, the output looks like this: DTSA: ==== centerim 4.22.1-2lenny1: DTSA-55-1 : centerim - arbitrary code execution CVE-2007-3713: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3713 Migrated from unstable: ====================== libpam-usb 0.4.1-1: <no CVE yet> : pam usb wrongly allows authentication without password in ssh sessions (TEMP-0000000-000573) streamripper 1.62.2a-1: CVE-2007-4337: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4337 Removed from testing: ==================== acidlab: CVE-2006-1590: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1590 I think we could create some daily or weekly summary mails from this data. Is this a useful format? Should we include the long descriptions from the CVEs? I think those are too long. Or is there a source for short descriptions for CVEs that I don''t know about? For removed packages, there is the problem that (AFAIK) the release team sometimes removes packages temporarily to ease transitions. This could be confusing for the users. Should the information about removed packages be included? Should we include other information, like scores from NVD or our priorities? In the last week, there have been 0-4 issues fixed per day. Do we want daily or weekly summary mails? For now, the daily output of the script is at http://www.sfritsch.de/~dst/ If you notice any inconsistencies, please tell me. Cheers, Stefan
Hi> I think we could create some daily or weekly summary mails from this > data. Is this a useful format? Should we include the long descriptions > from the CVEs? I think those are too long. Or is there a source for short > descriptions for CVEs that I don''t know about?I think the output looks alright. There should probably be a template around it explaining the upgrade and so on. I still think that the DTSAs should come with different announcements, to either give them some information, show that they are on security.debian.org and i found them overall informative (but that just might be my personal opinion).> For removed packages, there is the problem that (AFAIK) the release team > sometimes removes packages temporarily to ease transitions. This could be > confusing for the users. Should the information about removed packages be > included?If the package is removed from testing, it does not mean that the user removes it from their installation, therefore the issue is not fixed. Because of that, I would not include this information.> Should we include other information, like scores from NVD or our > priorities? > > In the last week, there have been 0-4 issues fixed per day. Do we want > daily or weekly summary mails?I would go for daily mails or every 2-3 days, because the users want to get the security information as fast as possible. Thanks for the work. Do you want to commit the scripts to svn? Cheers Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070902/330c12c8/attachment.pgp
On Sun, September 2, 2007 04:40, Steffen Joeris wrote:>> For removed packages, there is the problem that (AFAIK) the release >> team sometimes removes packages temporarily to ease transitions. This >> could be confusing for the users. Should the information about removed >> packages be included? > If the package is removed from testing, it does not mean that the user > removes it from their installation, therefore the issue is not fixed. > Because of > that, I would not include this information.I would include it, but not with the claim that the issue is thereby "fixed". If we tell the admin that we decided to remove a package from the distribution because it''s not secure, that admin can decide for himself whether to: also uninstall the package, take other action to secure it or decide that the risk is acceptable/not applicable. If we leave the information out entirely, they are not prompted and may just keep on waiting for a security fix (or are ignorant about the problem entirely). Thijs
Stefan Fritsch wrote:> Hi, > > I wrote some scripts to determine which issues are fixed by migration, > DTSA, or removal from testing. Issues that are "fixed" by downgrading > to unimportant or not-affected are not included. Currently, the output > looks like this:Very nice. If generated daily, this can replace the DTSA mails fully.> DTSA: > ====> > centerim 4.22.1-2lenny1: > DTSA-55-1 : centerim - arbitrary code execution > CVE-2007-3713: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3713 > > > Migrated from unstable: > ======================> > libpam-usb 0.4.1-1: > <no CVE yet> : pam usb wrongly allows authentication without password in ssh sessions (TEMP-0000000-000573)I would omit the TEMP-foo, it''s internal to the tracker and doesn''t provide additional useful information.> Removed from testing: > ====================> > acidlab: > CVE-2006-1590: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1590 > > > I think we could create some daily or weekly summary mails from this > data. Is this a useful format? Should we include the long descriptions > from the CVEs? I think those are too long. Or is there a source for short > descriptions for CVEs that I don''t know about?I believe the link is enough. You could also like to the Debian bugs if available.> For removed packages, there is the problem that (AFAIK) the release team > sometimes removes packages temporarily to ease transitions. This could be > confusing for the users. Should the information about removed packages be > included?Yes, but with a note, that people will need to remove the package locally as well. OTOH, there can be false positives if a package has been removed for transitions or something similar.> Should we include other information, like scores from NVD or our priorities?I don''t recommend that. The NVD scores are weird and ours are only used for priorization so far.> In the last week, there have been 0-4 issues fixed per day. Do we want daily > or weekly summary mails?IMO daily.> For now, the daily output of the script is at > http://www.sfritsch.de/~dst/ > If you notice any inconsistencies, please tell me.Does it handle "retroactive" fixes? I.e. if a package has been fixed a week ago and it has only been added to the tracker later. Cheers, Moritz
First of all, thanks a lot Steffan, this is great! * Thijs Kinkhorst <thijs at debian.org> [070902 01:13]:> On Sun, September 2, 2007 04:40, Steffen Joeris wrote: > >> For removed packages, there is the problem that (AFAIK) the release > >> team sometimes removes packages temporarily to ease transitions. This > >> could be confusing for the users. Should the information about removed > >> packages be included? > > If the package is removed from testing, it does not mean that the user > > removes it from their installation, therefore the issue is not fixed. > > Because of > > that, I would not include this information. > > If we leave the information out entirely, they are not prompted and may > just keep on waiting for a security fix (or are ignorant about the problem > entirely).Correct me if I am wrong here, but this script is not meant to replace debsecan, which is used to keep the user/admin updated about the security situation on their box. This script, and its output, is to help raise the profile of the security testing team''s work by filling in the giant gap in people''s understanding about what our team accomplishes. Previously people only understood the Secure-Testing team''s work by looking at what DTSAs were published over the year and concluding incorrectly that we have done very little over the year. Its understandable how people could come to this conclusion because there is no clear profile of all the issues that have been fixed in the testing distribution and the number of DTSAs is actually quite small because many of the issues that we can fix we can do without needing to issue a DTSA. This metric for measuring our productivity is a false one, based on the correct one that can be used to measure the stable security team''s work. The difference between the two is great however as many issues are fixed through mechanisms other than DTSAs, such as through NMUs, migrations, bugs filed, maintainers poked and buildd manangers prodded. Its my understanding that this script''s output is to help change that metric, fill that gap and make it clearer the work that is being done by everyone here! Micah
On Sun, September 2, 2007 21:35, Micah Anderson wrote:> Its my understanding that this script''s output is to help change that > metric, fill that gap and make it clearer the work that is being done by > everyone here!Yes, that is an important feature of the script. But I suspect that if the mails are there, admins are going to use it too, whether that was our intention or not. Better keep it clear for them aswell, that doesn''t hurt the original motivation and may serve them better. Thijs
On Sunday 02 September 2007, Moritz Muehlenhoff wrote:> > For now, the daily output of the script is at > > http://www.sfritsch.de/~dst/ > > If you notice any inconsistencies, please tell me. > > Does it handle "retroactive" fixes? I.e. if a package has been > fixed a week ago and it has only been added to the tracker later.No, it''s a very simple script. I just let the tracker create its database once with the old and once with the new package files, and then look for differences in the testing_status table. I could probably keep older package files, too, and display new issues if they have been fixed by migration from unstable in the last week. I will look at this. Cheers, Stefan
On Sunday 02 September 2007, Thijs Kinkhorst wrote:> On Sun, September 2, 2007 21:35, Micah Anderson wrote: > > Its my understanding that this script''s output is to help change > > that metric, fill that gap and make it clearer the work that is > > being done by everyone here! > > Yes, that is an important feature of the script. But I suspect that > if the mails are there, admins are going to use it too, whether > that was our intention or not. Better keep it clear for them > aswell, that doesn''t hurt the original motivation and may serve > them better.Yes, I agree with you here. We should inform the admin that he might need to uninstall a package, but with a warning about the corner cases. On making the team more visible: Maybe it would be nice if our NMU strike force (mostly white+nion, I guess) could maintain a list what packages they NMU for security reasons. We might want to mention the number in the next "bits from testing security team" mail. Cheers, Stefan
Hi> On making the team more visible: Maybe it would be nice if our NMU > strike force (mostly white+nion, I guess) could maintain a list what > packages they NMU for security reasons. We might want to mention the > number in the next "bits from testing security team" mail.I added a new list into svn data/NMU/list . There we can add all the NMUs for unstable we are doing for the testing-security team. Not quite sure, if they should be integrated into the tracker somehow. I added my NMUs out of my memory, I might have missed some though :/ @nion: Please add your NMUs as well. Cheers Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070904/6f2ee8db/attachment.pgp
On Monday 03 September 2007, Stefan Fritsch wrote:> On Sunday 02 September 2007, Moritz Muehlenhoff wrote: > > Does it handle "retroactive" fixes? I.e. if a package has been > > fixed a week ago and it has only been added to the tracker later. > > No, it''s a very simple script. I just let the tracker create its > database once with the old and once with the new package files, and > then look for differences in the testing_status table. > > I could probably keep older package files, too, and display new > issues if they have been fixed by migration from unstable in the > last week. I will look at this.This does not really fit into the current implementation of the script. I would have to keep track of which fixes have already been announced, and I would have to keep quite a lot of old package files around. Maybe I will find a more elegant solution later... I think we can use the current script for the time being, and add handling of "retroactive" fixes later. An example mail will be sent to secure-testing-team later, so that you can fix all the typos ;-) Cheers, Stefan