Hello People, I'm part of the SquirrelMail development team and have assisted Jeroen in preparing the recent upload of a new SquirrelMail package.
Let me comment on some of the issues raised. First off, Debian is using an archaic version of SquirrelMail, being more than two years old (which is a lot for a product that is under active development). I would advise the Debian project of upgrading their packages more often; for example targeting for a yearly new stable release. The current policy harms Debian users: in these two years we've fixed hundreds of bugs (if not more) and made huge improvements to the code. I guess this goes for many more of the packages in Woody. Security fixes are not easily backportable to code that has changed so much since then. About the SquirrelMail Debian maintainership; this hasn't been up to par for the last half year (and before that was also not very active). A development version (1.5.0) was added to Debian (why??) and bug reports were not attended to, mail was not replied to at all(!). Debian should have some kind of mechanism to prevent this from happening in the future. Perhaps there should be a policy that each package has at least two maintainers? For the SquirrelMail package I'd say that Jeroen and Sam become co-maintainers. About security fixes in the SquirrelMail code; SquirrelMail does not (contrary to Roman's standpoint) adhere to a obscurity-policy but in stead openly discloses any security fix in our code. In the changelog and in the announcement of the recent 1.4.3 release it's clearly stated that this closes a security hole. If the Debian project wants to we can of course notify them if we patch something but it is principally their responsibility to monitor our lists, announcements and bugtraq. The bottom line is that in my opinion the quality of the Debian package "stands or falls" with the activity of the maintainer. Every package should have two active maintainers as a rule, not as an exception. I hope we can continue the collaboration like Jeroen and I did when preparing the recent upload. The close contact between development team and Debian maintainer turned out to be very efficient. Thijs >>> Sam, could you please forward you incoming mail about security issues >>> to someone who has more time to look into it? >> >> Well, I wouldn't lose time doing so. Better to upgrade to latest >> 1.4.3a. >> Yes, contrary to the Debian "backporting" policy, but in this case there >> are sufficient reasons to make the exception (and it's less >> "intrusive" >> than completely removing SM from Woody, as I listened before). I >> wouldn't trust an old 1.2.6 version; not without some guarantees than SM >> team would provide a detailed info of applied security fixes. And that's >> not the case, as stated by Matt. In this case, I agree with him: SM team >> should make a little effort to document such bugs instead of silently >> patching. I told this to SM developpers when I contacted them one month >> ago. Security through obscurity is not good at all. > > I agree with what you say about the SM team, as much as getting a > cc/forward of commit mails that fix a security issue, would already be > great. > > Simply putting a new major upstream release (1.4.x instead of 1.2.x) > won't be accepted for a security update, and also because XSS issues are > not that a severe issue, I don't think there is any reason to remove 1.2.x > from woody. Those XSS, and especially the SQL injection needs to be fixed > though. > > Thanks for your very detailed mail, I'll look into it w.r.t. remaining > woody issues. I also saw three CVE's assigned to squirrelmail in 2004, none > of them have been patched by Debian. I'll trace that down. > >>>> I disclosed in a _detailed way_ several bugs: >>>> [RS-2004-1] http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt >>>> >>> >>> This wasn't reported in the Debian BTS. >>> >> >> I was unaware of Debian BTS when I reported the vuln. Anyway, it should >> be sufficient to notify it to security email address. People who reports >> security bugs doesn't necesarily need to know about bug tracking >> systems or the way a "vendor" archives or deals with a reported bug. >> >> Moreover, security teams should monitorize public security >> mailing-lists like Bugtraq. So if the usual communication channels fail >> (for instance, >> e-mail to security address), at least you are aware of public vulns) >> (and >> then you can feed your internal / external BTS, or act as whatever you >> want). > > I fully agree with you, sorry, I didn't intend to 'blame' you for not > reporting it in the BTS. It would have made things easier/go faster, but I > agree, it is by no means your fault it didn't happen. It'd be appreciated > if you could do so though. > >>> I (the person uploading that version) was not aware of this, partly >>> because you didn't file a bug in the BTS about this. Note however that >>> >> >> As I have told, to "file a bug" is not my duty (although I would have >> made it if I had known of BTS' existence). I reported the bug to SM >> developpers (_before_ making it public, that's important, and letting >> sufficient time for the bug to be fixed) and also to Debian maintainer >> _as a courtesy_ (I >> don't have the time nor resources to notify all distros which use SM; I >> did the exception with Debian because I use Debian and I like it). > > Then the problem was with Debian internally, that this wasn't > forwarded/fixed... again, sorry for insinuating you should have filed a bug > :) > > >>>> - I don't know whether or not the old XSS bugs which I reported to >>>> affect Debian Woody (read RS-2004-1) are still uncovered. I'm afraid >>>> it is... >>> >>> Thanks for the direct pointer, I assume you did contact >>> [EMAIL PROTECTED] about this? >> >> I should check my outbox to verify this (I think I placed >> [EMAIL PROTECTED] in cc). In all cases: - You can assume _at least_ >> Debian maintainer (Sam) was notified. >> > > ... > > >> - I recall to have talked about this with Matt, so I assume he is / was >> also aware of this. Indeed he replied in a public mailing-list to my >> advisory post so he should read it: >> http://seclists.org/lists/fulldisclosure/2004/Jun/0029.html >> > > I don't know what happened to this. In answer to this question of yours: > > > http://seclists.org/lists/fulldisclosure/2004/Jun/0046.html > | ---- > | #ifdef _security_perspective_ > | #define usual_channels bugtraq other_lists > | #endif > | #ifdef _devel_perspective_ > | #define usual_channels changelog_file > | #endif > | printf("My usual channels are: %s", usual_channels); > | ---- > | It was some kind of pseudocode :-) Question: which perspective are > | using Debian maintainers to monitorize their packages? In the > | particular case of SM, the old XSS issues were listed in ChangeLog, > | but .deb package was not updated. Why? > > > Debian maintainers should monitor upstream, especially changelogs of new > versions, and preferable also upstream devel mailinglists. > > The .deb package was not updated because the Debian maintainer for > squirrelmail was too busy, why the security team didn't update woody yet, > maybe they were too busy too. I have a suggestion how to potentially > improve this, I'll send a separate mail about it. > >>> But Debian unstable keeps getting lots of other bugs, so is often no >>> alternative :) >> >> Well, from security perspective I prefer unstable. Same applies to >> "usability" perspective (I don't like outdated versions of certain >> software). Again this is my personal opinion. I respect Debian Woody >> policy but I don't support it. Better not to speak about this >> (flame-war >> risk! :-)). > > You're of course entitled to your own opinion. We shall agree to > disagree on this issue then :). > >>> If Debian isn't notified of security bugs, they can't fix them. Weird >>> >> >> Don't blame me. Your statement is easily refutable: "If Debian >> maintainers don't answer to important mails (I know the email address >> was fine because I previosly had contacted Sam using the same method; >> and I insisted trying to re-contact) and Debian security team is unaware >> of public security mailing-lists (or they answer to certain threads >> without reading the original post :-?) it's not my fault". Please, don't >> start the war. I'm only defending my position :) > > Again, my fault, indeed, you've done all (and more) that one could > expect from you. It still remains true that also filing a bug will help > more, but I agree it's a Debian internal problem if indeed nothing > happened after this (I of course don't know what happened in private, so I > am not going to guess on whether or not action was taken). > >>> that you here claim unstable was free of these bugs, while above you >>> claim Debian unstable _had_ these bugs at the time of your advisory. >>> So, >>> which one of the two is it? Or are there more issues involved than the >>> ones detailed in RS-2004-1? > >> [elaborate explaination] >> > >> I hope this will clears things out. >> > > Thanks, indeed it does for me. > > > Bye, > --Jeroen > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
