From: Patrick S. <sch...@in...> - 2007-01-13 18:36:19
|
(sorry for eventually break the thread, but i haven't been subscribed to the list until now) Hi everybody, as some of you maybe know, I am the current debian maintainer for mantis. Therefore i would like to comment on this topic. Thanks to Udo Rader for dropping a note about this thread to me. > On Sat, 2007-01-13 at 00:01 +0100, Gianluca Sforna wrote: >> I'm not a developer, but I am packaging mantis for Fedora since some >> months now, so I would like to throw my 2 cents on the topic. >> >> On 1/12/07, Udo Rader <udo.rader@be...> wrote: >> > For a long time we were wondering why debian shipped 0.9.x even in their >> > "unstable" distribution and were surprized when a couple of weeks ago >> > mantis was upgraded to 1.0.x >> >> This was rather strange. Maybe it was just the lack of a packager? > > No, AFAIK it was not a lack of packager, though indeed it took a new > maintainer to have the latest stable release available in the unstable > tree of debian. Yes, it was due to a lack of a packager. There has been several packagers around, who got sick of maintaining mantis, as far as i heard. So mantis has been unmaintained for quiet a while (even though it hasn't been noted on the debian pages). >> > Yet we started to wonder again, why there was no upgrade to 1.1 and thus >> > checked some debian lists on why debian would not upgrade. >> >> well. this is _not_ strange, given that 1.1 is still in alpha state. >> Right now the stable mantis version is 1.0.6 > > Yes, that's probably the reason, though I was talking about debian > unstable here, so pre release versions not uncommon here. Well thats not very true. It is common to provide newer versions in unstable, but due to need of quality it is not good to provide packages which are yet known to be broken in there upgrade path. Generally, i do prefer to package software which is considered to be stable, as packages uploaded to unstable will and should get into testing. That was even more important for packaging a new version of mantis, as i tried to get it into debian stable (which is to be released in a while). > Well, I would call the following excerpt a clear statment that they > don't want to include it due to security concerns: Yeah, but this is more about history and for the reason that Debian security cannot know if quality has been enhanced (and work with upstream!) since the last version. Also I'm a new maintainer. So they frighten that i might not keep up interest in packaging mantis. In fact mantis packages has been in *very bad* state until i repackaged a newer version and got the maintainer of it. So a package that is better is in Debian/unstable just a short time. To short to see if it proves better or just good enough. So the Debian Security team is against including it in stable currently. Thats all. >> > Now all that I have read there makes me worry a bit and I would like to >> > know what you all say to this. >> >> My comments on the situation. In my archives for the mantisbt-dev >> mailing list, I can see a single occurrence of messages from >> someone@de.... >> I believe distro packagers should work more closely with the upstream >> projects, provide patches if available (expecially for security >> related bugs) and poke developers if they not release security fixes >> in a timely manner. Ha! Funny. In the whole thread about including my mantis packages into debian/stable i heard similar words from Debian developers. And i can understand the Debian developers better then mantis developers. Cause you don't make it easy for us to work close with upstream. That begins with keeping this list moderated for non-subscribed users and never let mails into the list nor answering them (i experienced this myself when i started work on mantis packages). You must understand that most debian developers do maintain more then just one package. And most of them have a life anyway. You can *not* subscribe every single list, every single software package provides. It *has to be* possible to reach upstream developers without subscribing a list. That does match up for security stuff at debian almost more. Because they do provide security upgrades for *all* packages in debian, with a limited number of human resources. So if that does not change the future of mantis in Debian, at least in the stable branch, will be unknown. Best Regards Patrick |
From: Victor B. <vb...@gm...> - 2007-01-16 08:50:48
|
Hi Udo, Patrick, Gianluca, Paul, Thanks for your inputs on this issue. Following are some of my ideas: 1. Mailing List - The reason we added moderation to the list is due to the huge amount of spam that we get on the list. I waste a lot of personal time on moderating this. I try not to do it everyday, hence, if we moderate all and remove requirement to subscribe, then some of messages will be delayed in the queues even for regular mailing list users. Ideas and feedback are welcome on this approach. I am sure this problem is not unique to Mantis. I wonder why sourceforge is not doing a better spam filtering job here! 2. Security Category - It seems that some packagers or distributions use our change log as their source of knowing Mantis security issues. This makes sense due to the lack of advisories (see below). Hence, the question is: are we using the security category wisely? For example, is 5163 a security issue? there are several issues that were resolved when the bug history security issue was fixed, should we have consolidated them in one, since they are all related to the fact that history entry were not secured? Should we split this category into sub-categories like information disclosure, cross scripting, etc - or should we clarify this in the security advisory?! These are all ideas that we need to think about it. 3. Provide Patches - It seems that packages maintain their own version of Mantis with patches that they apply, rather than always upgrading to the next stable release. This means that we need to implement fixes in CVS, port them to other branches, as well as provide patches that can be applied by the packagers as well as Mantis users who can't upgrade to the latest release. 4. Security Advisories - We should attempt to go back to what we used to do before, where we used to release security advisories with full documentation of the security issues, the versions they apply to and how existing installations can be patches (e.g. http://tinyurl.com/yk95rm ) 5. Mantis Packaging Team - Provide a couple of packagers with CVS commit access to commit patches and implement packing related improvements. These packagers should also be responsible for communcation with packagers, modifying code to be packaging friendly (e.g. non-interactive schema upgrade), write up security advisories, apply patches provided by packagers, document critical patches (e.g. security fixes), maintain list of packages that distribute Mantis. This is in addition to their duty as Mantis packagers on a specific distribution. Volunteers, please contact me!! I would love to have the same level of success with "Mantis Packaging Team" that we had with the "Mantis Globalization Team". By having a team that is focused on a certain domain, we can make a better job and relief the load on the developers that are working on the core functionality. Thanks again for your help with this issue. Success in this area will be a great step on wider distribution of Mantis and simplification of the process of deploying it for our users. On 1/13/07, Patrick Schoenfeld <sch...@in...> wrote: > (sorry for eventually break the thread, but i haven't been subscribed to > the list until now) > > Hi everybody, > > as some of you maybe know, I am the current debian maintainer for > mantis. Therefore i would like to comment on this topic. Thanks to Udo > Rader for dropping a note about this thread to me. > > > On Sat, 2007-01-13 at 00:01 +0100, Gianluca Sforna wrote: > >> I'm not a developer, but I am packaging mantis for Fedora since some > >> months now, so I would like to throw my 2 cents on the topic. > >> > >> On 1/12/07, Udo Rader <udo.rader@be...> wrote: > >> > For a long time we were wondering why debian shipped 0.9.x even in their > >> > "unstable" distribution and were surprized when a couple of weeks ago > >> > mantis was upgraded to 1.0.x > >> > >> This was rather strange. Maybe it was just the lack of a packager? > > > > No, AFAIK it was not a lack of packager, though indeed it took a new > > maintainer to have the latest stable release available in the unstable > > tree of debian. > > Yes, it was due to a lack of a packager. There has been several > packagers around, who got sick of maintaining mantis, as far as i heard. > So mantis has been unmaintained for quiet a while (even though it hasn't > been noted on the debian pages). > > >> > Yet we started to wonder again, why there was no upgrade to 1.1 and thus > >> > checked some debian lists on why debian would not upgrade. > >> > >> well. this is _not_ strange, given that 1.1 is still in alpha state. > >> Right now the stable mantis version is 1.0.6 > > > > Yes, that's probably the reason, though I was talking about debian > > unstable here, so pre release versions not uncommon here. > > Well thats not very true. It is common to provide newer versions in > unstable, but due to need of quality it is not good to provide packages > which are yet known to be broken in there upgrade path. Generally, i do > prefer to package software which is considered to be stable, as packages > uploaded to unstable will and should get into testing. That was even > more important for packaging a new version of mantis, as i tried to get > it into debian stable (which is to be released in a while). > > > Well, I would call the following excerpt a clear statment that they > > don't want to include it due to security concerns: > > Yeah, but this is more about history and for the reason that Debian > security cannot know if quality has been enhanced (and work with > upstream!) since the last version. Also I'm a new maintainer. So they > frighten that i might not keep up interest in packaging mantis. > > In fact mantis packages has been in *very bad* state until i repackaged > a newer version and got the maintainer of it. So a package that is > better is in Debian/unstable just a short time. To short to see if it > proves better or just good enough. So the Debian Security team is > against including it in stable currently. Thats all. > > >> > Now all that I have read there makes me worry a bit and I would like to > >> > know what you all say to this. > >> > >> My comments on the situation. In my archives for the mantisbt-dev > >> mailing list, I can see a single occurrence of messages from > >> someone@de.... > >> I believe distro packagers should work more closely with the upstream > >> projects, provide patches if available (expecially for security > >> related bugs) and poke developers if they not release security fixes > >> in a timely manner. > > Ha! Funny. In the whole thread about including my mantis packages into > debian/stable i heard similar words from Debian developers. And i can > understand the Debian developers better then mantis developers. Cause > you don't make it easy for us to work close with upstream. That begins > with keeping this list moderated for non-subscribed users and never let > mails into the list nor answering them (i experienced this myself when i > started work on mantis packages). You must understand that most debian > developers do maintain more then just one package. And most of them have > a life anyway. You can *not* subscribe every single list, every single > software package provides. It *has to be* possible to reach upstream > developers without subscribing a list. That does match up for security > stuff at debian almost more. Because they do provide security upgrades > for *all* packages in debian, with a limited number of human resources. > So if that does not change the future of mantis in Debian, at least in > the stable branch, will be unknown. > > Best Regards > > Patrick > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Gianluca S. <gi...@gm...> - 2007-01-17 09:51:01
|
On 1/16/07, Victor Boctor <vb...@gm...> wrote: > 1. Mailing List - The reason we added moderation to the list is due to > the huge amount of spam that we get on the list. I waste a lot of > personal time on moderating this. I try not to do it everyday, hence, > if we moderate all and remove requirement to subscribe, then some of > messages will be delayed in the queues even for regular mailing list > users. Ideas and feedback are welcome on this approach. I am sure > this problem is not unique to Mantis. I wonder why sourceforge is not > doing a better spam filtering job here! Practically all the mailing lists I am subscribed to allow posts from subscribers only, so I guess you are doing the right thing. For the issue of allowing posts from non subscribed users, I usully use the gmane gateway. I think it will be enough to document you can post here from: http://news.gmane.org/gmane.comp.bug-tracking.mantis.devel > > 2. Security Category - It seems that some packagers or distributions > use our change log as their source of knowing Mantis security issues. Yes, I got the same impression > This makes sense due to the lack of advisories (see below). Hence, > the question is: are we using the security category wisely? Probably we can improve. > For > example, is 5163 a security issue? I don't think so (but I'm not in the security field) > there are several issues that were > resolved when the bug history security issue was fixed, should we have > consolidated them in one, since they are all related to the fact that > history entry were not secured? This is a tricky call. It probably makes sense to have a parent issue for all of them > Should we split this category into > sub-categories like information disclosure, cross scripting, etc - or > should we clarify this in the security advisory?! It is probably not necessary to split the category, but bugs classified as security should require some special care in the description. We could borrow a template from somewhere. For example, https://www.redhat.com/archives/fedora-package-announce/2007-January/msg00051.html > > 3. Provide Patches - It seems that packages maintain their own version > of Mantis with patches that they apply, rather than always upgrading > to the next stable release. True, but not all distributions are affected to the same extent. Fedora tries to stick as close as possible to upstream, so patches should be only related to packaging and security stuff not yet covered by an upstream release. For example, I had to roll an update recently to fix bug 7364, since 1.0.6 is affected > This means that we need to implement > fixes in CVS, port them to other branches, as well as provide patches > that can be applied by the packagers as well as Mantis users who can't > upgrade to the latest release. Eventually, attach them to the issue when resolving. > > 4. Security Advisories - We should attempt to go back to what we used > to do before, where we used to release security advisories with full > documentation of the security issues, the versions they apply to and > how existing installations can be patches (e.g. > http://tinyurl.com/yk95rm ) Nice, but IMHO not strictly required if the security category is handled properly and, for example, attached to a RSS feed > > 5. Mantis Packaging Team - Provide a couple of packagers with CVS > commit access to commit patches and implement packing related > improvements. Should be nice to have... > These packagers should also be responsible for > communcation with packagers, modifying code to be packaging friendly > (e.g. non-interactive schema upgrade), write up security advisories, > apply patches provided by packagers, document critical patches (e.g. > security fixes), maintain list of packages that distribute Mantis. > This is in addition to their duty as Mantis packagers on a specific > distribution. I am already doing some of that is listed, but I lack the proper undestanding to document security flaws. Anyone else is interested? |
From:
<sch...@in...> - 2007-01-17 10:34:44
|
Hi Victor, sorry for my late reply - currently I'm quiet busy with my job and some other stuff (like moving to another flat). Let's see if I got something to say: Victor Boctor wrote: > 1. Mailing List - The reason we added moderation to the list is due to > the huge amount of spam that we get on the list. I waste a lot of > personal time on moderating this. I try not to do it everyday, hence, > if we moderate all and remove requirement to subscribe, then some of > messages will be delayed in the queues even for regular mailing list > users. Ideas and feedback are welcome on this approach. I am sure > this problem is not unique to Mantis. I wonder why sourceforge is not > doing a better spam filtering job here! In fact i don't see a concrete reason to open it up. You can leave it like it is, BUT (a big but!) then you really should do the moderation properly. For example: I've written a mail to the -dev list about database upgrade procedure on 24th november, which were quiet important for me this time, to can have a new mantis version packaged in Debian at all. It never entered the mailing list (I've recently rechecked the archives). That is bad. Imagine: Someone from Debian Security finds a bug. Now he tries to contact you, but logically he is *not* subscribed to the list. Will he be ignored like this, too? > 2. Security Category - It seems that some packagers or distributions > use our change log as their source of knowing Mantis security issues. Maybe. Does not match for me, or as far as I can speak for them, for others in the Debian project. But it is used to search for your solutions, which makes sense, cause there is no other good source for it, as you will state in the next sentence. > This makes sense due to the lack of advisories (see below). Hence, > the question is: are we using the security category wisely? For > example, is 5163 a security issue? there are several issues that were > resolved when the bug history security issue was fixed, should we have > consolidated them in one, since they are all related to the fact that > history entry were not secured? Should we split this category into > sub-categories like information disclosure, cross scripting, etc - or > should we clarify this in the security advisory?! These are all ideas > that we need to think about it. Well, when I was searching for some recent flaws in mantis I've found reports for them. It wasn't easy to associate them with the advisories I've read because the descriptions varied a lot. But thats not the biggest problem. More bigger is the problem that some bugreports contain a solution, some not. Some contain much information about the problem (mostly/almost only if users find a solution) so that it can be backported to older versions, some contain at least a filename and a line number, some does not contain informations about the bug at all, except that it is fixed in the current developer version. So IMO important would be to: a) Split Category in sub-categories like you said (makes association easier) b) Take some time to describe the problem and a solution which is reproducible. Cause if i maintain mantis/stable in Debian it does not help me much if you fix bugs in a devel/instable version. I need to know how I can implement your fixes in the stable version. > 3. Provide Patches - It seems that packages maintain their own version > of Mantis with patches that they apply, rather than always upgrading > to the next stable release. This means that we need to implement > fixes in CVS, port them to other branches, as well as provide patches > that can be applied by the packagers as well as Mantis users who can't > upgrade to the latest release. At the debian project we mostly try to stay sync with the current stable version, except that we add a 'debian' folder which contains the files for eventually needed patches and for the packaging. We try not to change to much. But in case of mantis I had to replace the RSS api, cause it is to be considered non-free (e.g. with this RSS api mantis can *not* be used in companies without doing something against the law!). But yeah: It would be a good idea to provide patches. At least for your current stable version. I'm pretty sure that would make users of mantis/stable (without using distribution packages) a lot of happier, too. Cause now it seems as if you would fix security bugs only in your developer versions. > 4. Security Advisories - We should attempt to go back to what we used > to do before, where we used to release security advisories with full > documentation of the security issues, the versions they apply to and > how existing installations can be patches (e.g. > http://tinyurl.com/yk95rm ) Yes you could do this OR just add proper informations into the bugtracker. A page with links to this bug reports at a prominent place would be a plus but definitely NOT needed. > 5. Mantis Packaging Team - Provide a couple of packagers with CVS > commit access to commit patches and implement packing related > improvements. These packagers should also be responsible for > communcation with packagers, modifying code to be packaging friendly > (e.g. non-interactive schema upgrade), write up security advisories, > apply patches provided by packagers, document critical patches (e.g. > security fixes), maintain list of packages that distribute Mantis. > This is in addition to their duty as Mantis packagers on a specific > distribution. Volunteers, please contact me!! May be a good idea, although i cannot help you, cause i lack the time for another duty. Also i miss knowledge for some of the work that would need to be done. Otherwise I'm not sure if that is needed. Distribution specific patches should be kept separate from the upstream distribution and a lot of the other tasks is basically documenting what your developers do. They should be able to document this as part of their work. Basically this is a task which every developer has to do. Apart from this: It would be great if you could just let an SQL file exist (apart from install.php) for the upgrade job. AFAIR you did have such an SQL file earlier and that is at all the best you can give to packagers (at least for me @ debian). Well, i hope we all find a solution for our problems. The current stand is: Debian Security will not support mantis in Debian Etch, so it will not be included in Etch. They stated that they could not work with you properly in the past. This should really change to get mantis back in Debian/stable for the release *after* etch (for etch it is too late). And this one is fact: Having packages in distributions is definitely helping your users and also will help getting new users. Best regards Patrick > On 1/13/07, Patrick Schoenfeld <sch...@in...> wrote: >> (sorry for eventually break the thread, but i haven't been subscribed to >> the list until now) >> >> Hi everybody, >> >> as some of you maybe know, I am the current debian maintainer for >> mantis. Therefore i would like to comment on this topic. Thanks to Udo >> Rader for dropping a note about this thread to me. >> >>> On Sat, 2007-01-13 at 00:01 +0100, Gianluca Sforna wrote: >>>> I'm not a developer, but I am packaging mantis for Fedora since some >>>> months now, so I would like to throw my 2 cents on the topic. >>>> >>>> On 1/12/07, Udo Rader <udo.rader@be...> wrote: >>>>> For a long time we were wondering why debian shipped 0.9.x even in their >>>>> "unstable" distribution and were surprized when a couple of weeks ago >>>>> mantis was upgraded to 1.0.x >>>> This was rather strange. Maybe it was just the lack of a packager? >>> No, AFAIK it was not a lack of packager, though indeed it took a new >>> maintainer to have the latest stable release available in the unstable >>> tree of debian. >> Yes, it was due to a lack of a packager. There has been several >> packagers around, who got sick of maintaining mantis, as far as i heard. >> So mantis has been unmaintained for quiet a while (even though it hasn't >> been noted on the debian pages). >> >>>>> Yet we started to wonder again, why there was no upgrade to 1.1 and thus >>>>> checked some debian lists on why debian would not upgrade. >>>> well. this is _not_ strange, given that 1.1 is still in alpha state. >>>> Right now the stable mantis version is 1.0.6 >>> Yes, that's probably the reason, though I was talking about debian >>> unstable here, so pre release versions not uncommon here. >> Well thats not very true. It is common to provide newer versions in >> unstable, but due to need of quality it is not good to provide packages >> which are yet known to be broken in there upgrade path. Generally, i do >> prefer to package software which is considered to be stable, as packages >> uploaded to unstable will and should get into testing. That was even >> more important for packaging a new version of mantis, as i tried to get >> it into debian stable (which is to be released in a while). >> >>> Well, I would call the following excerpt a clear statment that they >>> don't want to include it due to security concerns: >> Yeah, but this is more about history and for the reason that Debian >> security cannot know if quality has been enhanced (and work with >> upstream!) since the last version. Also I'm a new maintainer. So they >> frighten that i might not keep up interest in packaging mantis. >> >> In fact mantis packages has been in *very bad* state until i repackaged >> a newer version and got the maintainer of it. So a package that is >> better is in Debian/unstable just a short time. To short to see if it >> proves better or just good enough. So the Debian Security team is >> against including it in stable currently. Thats all. >> >>>>> Now all that I have read there makes me worry a bit and I would like to >>>>> know what you all say to this. >>>> My comments on the situation. In my archives for the mantisbt-dev >>>> mailing list, I can see a single occurrence of messages from >>>> someone@de.... >>>> I believe distro packagers should work more closely with the upstream >>>> projects, provide patches if available (expecially for security >>>> related bugs) and poke developers if they not release security fixes >>>> in a timely manner. >> Ha! Funny. In the whole thread about including my mantis packages into >> debian/stable i heard similar words from Debian developers. And i can >> understand the Debian developers better then mantis developers. Cause >> you don't make it easy for us to work close with upstream. That begins >> with keeping this list moderated for non-subscribed users and never let >> mails into the list nor answering them (i experienced this myself when i >> started work on mantis packages). You must understand that most debian >> developers do maintain more then just one package. And most of them have >> a life anyway. You can *not* subscribe every single list, every single >> software package provides. It *has to be* possible to reach upstream >> developers without subscribing a list. That does match up for security >> stuff at debian almost more. Because they do provide security upgrades >> for *all* packages in debian, with a limited number of human resources. >> So if that does not change the future of mantis in Debian, at least in >> the stable branch, will be unknown. >> >> Best Regards >> >> Patrick >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Mantisbt-dev mailing list >> Man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- in medias res Gesellschaft für Kommunikationstechnologien mbH Dahlenerstr. 570 41239 Mönchengladbach tel. +49 (0) 2166 - 9999685 fax. +49 (0) 2166 - 9999800 email: sch...@in... |
From: Gianluca S. <gi...@gm...> - 2007-01-17 12:24:39
|
T24gMS8xNy8wNywgInNjaMO2bmZlbGQgLyBpbi1tZWRpYXMtcmVzLmNvbSIKPHNjaG9lbmZlbGRA aW4tbWVkaWFzLXJlcy5jb20+IHdyb3RlOgo+IEluIGZhY3QgaSBkb24ndCBzZWUgYSBjb25jcmV0 ZSByZWFzb24gdG8gb3BlbiBpdCB1cC4gWW91IGNhbiBsZWF2ZSBpdAo+IGxpa2UgaXQgaXMsIEJV VCAoYSBiaWcgYnV0ISkgdGhlbiB5b3UgcmVhbGx5IHNob3VsZCBkbyB0aGUgbW9kZXJhdGlvbgo+ IHByb3Blcmx5LiBGb3IgZXhhbXBsZTogSSd2ZSB3cml0dGVuIGEgbWFpbCB0byB0aGUgLWRldiBs aXN0IGFib3V0Cj4gZGF0YWJhc2UgdXBncmFkZSBwcm9jZWR1cmUgb24gMjR0aCBub3ZlbWJlciwg d2hpY2ggd2VyZSBxdWlldCBpbXBvcnRhbnQKPiBmb3IgbWUgdGhpcyB0aW1lLCB0byBjYW4gaGF2 ZSBhIG5ldyBtYW50aXMgdmVyc2lvbiBwYWNrYWdlZCBpbiBEZWJpYW4gYXQKPiBhbGwuIEl0IG5l dmVyIGVudGVyZWQgdGhlIG1haWxpbmcgbGlzdCAoSSd2ZSByZWNlbnRseSByZWNoZWNrZWQgdGhl Cj4gYXJjaGl2ZXMpLgpEb2luZyB0aGluZ3MgbWFudWFsbHkgaXMgYWx3YXlzIGVycm9yZSBwcm9u ZS4uLiBNeSBwcmVmZXJyZWQgb3B0aW9uIGlzCnN0aWxsOiBubyBtb2RlcmF0aW9uLCBidXQgcG9z dHMgYWxsb3dlZCBvbmx5IGZyb20gc3Vic2NyaWJlcnMuCgo+ID4gVGhpcyBtYWtlcyBzZW5zZSBk dWUgdG8gdGhlIGxhY2sgb2YgYWR2aXNvcmllcyAoc2VlIGJlbG93KS4gIEhlbmNlLAo+ID4gdGhl IHF1ZXN0aW9uIGlzOiBhcmUgd2UgdXNpbmcgdGhlIHNlY3VyaXR5IGNhdGVnb3J5IHdpc2VseT8g IEZvcgo+ID4gZXhhbXBsZSwgaXMgNTE2MyBhIHNlY3VyaXR5IGlzc3VlPyAgdGhlcmUgYXJlIHNl dmVyYWwgaXNzdWVzIHRoYXQgd2VyZQo+ID4gcmVzb2x2ZWQgd2hlbiB0aGUgYnVnIGhpc3Rvcnkg c2VjdXJpdHkgaXNzdWUgd2FzIGZpeGVkLCBzaG91bGQgd2UgaGF2ZQo+ID4gY29uc29saWRhdGVk IHRoZW0gaW4gb25lLCBzaW5jZSB0aGV5IGFyZSBhbGwgcmVsYXRlZCB0byB0aGUgZmFjdCB0aGF0 Cj4gPiBoaXN0b3J5IGVudHJ5IHdlcmUgbm90IHNlY3VyZWQ/ICBTaG91bGQgd2Ugc3BsaXQgdGhp cyBjYXRlZ29yeSBpbnRvCj4gPiBzdWItY2F0ZWdvcmllcyBsaWtlIGluZm9ybWF0aW9uIGRpc2Ns b3N1cmUsIGNyb3NzIHNjcmlwdGluZywgZXRjIC0gb3IKPiA+IHNob3VsZCB3ZSBjbGFyaWZ5IHRo aXMgaW4gdGhlIHNlY3VyaXR5IGFkdmlzb3J5PyEgIFRoZXNlIGFyZSBhbGwgaWRlYXMKPiA+IHRo YXQgd2UgbmVlZCB0byB0aGluayBhYm91dCBpdC4KPgo+IFdlbGwsIHdoZW4gSSB3YXMgc2VhcmNo aW5nIGZvciBzb21lIHJlY2VudCBmbGF3cyBpbiBtYW50aXMgSSd2ZSBmb3VuZAo+IHJlcG9ydHMg Zm9yIHRoZW0uIEl0IHdhc24ndCBlYXN5IHRvIGFzc29jaWF0ZSB0aGVtIHdpdGggdGhlIGFkdmlz b3JpZXMKPiBJJ3ZlIHJlYWQgYmVjYXVzZSB0aGUgZGVzY3JpcHRpb25zIHZhcmllZCBhIGxvdC4K Q1ZFIG51bWJlcnMgYXJlIHRoZXJlIGZvciBhIHJlYXNvbjogdGhleSBzaG91bGQgYmUgQUxXQVlT IHJlZmVyZW5jZWQKaW4gdGhlIGJ1ZyBzdW1tYXJ5Cgo+IGEpIFNwbGl0IENhdGVnb3J5IGluIHN1 Yi1jYXRlZ29yaWVzIGxpa2UgeW91IHNhaWQgKG1ha2VzIGFzc29jaWF0aW9uIGVhc2llcikKPiBi KSBUYWtlIHNvbWUgdGltZSB0byBkZXNjcmliZSB0aGUgcHJvYmxlbSBhbmQgYSBzb2x1dGlvbiB3 aGljaCBpcwo+IHJlcHJvZHVjaWJsZS4gQ2F1c2UgaWYgaSBtYWludGFpbiBtYW50aXMvc3RhYmxl IGluIERlYmlhbiBpdCBkb2VzIG5vdAo+IGhlbHAgbWUgbXVjaCBpZiB5b3UgZml4IGJ1Z3MgaW4g YSBkZXZlbC9pbnN0YWJsZSB2ZXJzaW9uLiBJIG5lZWQgdG8ga25vdwo+IGhvdyBJIGNhbiBpbXBs ZW1lbnQgeW91ciBmaXhlcyBpbiB0aGUgc3RhYmxlIHZlcnNpb24uCisxLgpUaGUgYmVzdCBJTUhP IHdvdWxkIGJlIGEgcG9pbnQgcmVsZWFzZSBhcyBzb29uIGFzIHRoZSBzZWN1cml0eSBwcm9ibGVt IGlzIGZpeGVkCgo+IEJ1dCBpbiBjYXNlIG9mIG1hbnRpcyBJIGhhZCB0byByZXBsYWNlIHRoZSBS U1MgYXBpLAo+IGNhdXNlIGl0IGlzIHRvIGJlIGNvbnNpZGVyZWQgbm9uLWZyZWUgKGUuZy4gd2l0 aCB0aGlzIFJTUyBhcGkgbWFudGlzIGNhbgo+ICpub3QqIGJlIHVzZWQgaW4gY29tcGFuaWVzIHdp dGhvdXQgZG9pbmcgc29tZXRoaW5nIGFnYWluc3QgdGhlIGxhdyEpLgpBQVJHSCEgSSBkaWQgbm90 IHJlYWxpemVkIHRoaXMgYmVmb3JlIDooCkkgaGF2ZSB0byBkbyB0aGUgc2FtZSBmb3IgRmVkb3Jh LCBvciB0aGUgcGFja2FnZSBjYW4gYmUgcmVtb3ZlZCBmcm9tIHRoZSByZXBvLgoKQ2FuIHlvdSBj b25zaWRlciB1c2luZyBhbm90aGVyIG9uZSB3aXRob3V0IHRoZSBjb21tZXJjaWFsIHVzZSByZXN0 cmljdGlvbj8KCj4KPiBCdXQgeWVhaDogSXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gcHJvdmlk ZSBwYXRjaGVzLiBBdCBsZWFzdCBmb3IgeW91cgo+IGN1cnJlbnQgc3RhYmxlIHZlcnNpb24uIEkn bSBwcmV0dHkgc3VyZSB0aGF0IHdvdWxkIG1ha2UgdXNlcnMgb2YKPiBtYW50aXMvc3RhYmxlICh3 aXRob3V0IHVzaW5nIGRpc3RyaWJ1dGlvbiBwYWNrYWdlcykgYSBsb3Qgb2YgaGFwcGllciwKPiB0 b28uIENhdXNlIG5vdyBpdCBzZWVtcyBhcyBpZiB5b3Ugd291bGQgZml4IHNlY3VyaXR5IGJ1Z3Mg b25seSBpbiB5b3VyCj4gZGV2ZWxvcGVyIHZlcnNpb25zLgpOb3QgcmVhbGx5IHRydWUuIEFGQUlD VCBzZWN1cml0eSBidWdzIGFyZSBmaXhlZCBfZmlyc3RfIGluIHRoZQpkZXZlbG9wbWVudCB2ZXJz aW9uLCBidXQgdGhleSBhcmUgdXN1YWxseSBjbG9uZWQgZm9yIHRoZSBsYXRlc3Qgc3RhYmxlCnJl bGVhc2UgYW5kIGZpeGVkIGFsc28gdGhlcmUgKHNlZSBhbHNvIHRoZSBDVlMgYnJhbmNoIGZvciAx LjAueApyZWxlYXNlcy4KV2UgcHJvYmFsYnkgaGF2ZSB0byBtYWtlIHN1cmUgQUxMIHNlY3VyaXR5 IGlzc3VlcyBoYXZlIGR1b2JsZSBlbnRyaWVzCmZvciByZWxlYXNlL2RldmVsIGJyYW5jaGVzCgoK PiBBcGFydCBmcm9tIHRoaXM6IEl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBjb3VsZCBqdXN0IGxl dCBhbiBTUUwgZmlsZQo+IGV4aXN0IChhcGFydCBmcm9tIGluc3RhbGwucGhwKSBmb3IgdGhlIHVw Z3JhZGUgam9iLiBBRkFJUiB5b3UgZGlkIGhhdmUKPiBzdWNoIGFuIFNRTCBmaWxlIGVhcmxpZXIg YW5kIHRoYXQgaXMgYXQgYWxsIHRoZSBiZXN0IHlvdSBjYW4gZ2l2ZSB0bwo+IHBhY2thZ2VycyAo YXQgbGVhc3QgZm9yIG1lIEAgZGViaWFuKS4KSSBhbSB3b3JraW5nIG9uIHRoZSB1cGRncmFkZSB0 b3BpYyAoc2VlIGJ1ZyA3NjYzKS4gV291bGQgeW91IGxpa2UgdG8KaGVscCBtZSBvbiB0aGF0Pwo= |
From:
<sch...@in...> - 2007-01-17 13:20:03
|
Gianluca Sforna wrote: > On 1/17/07, "schönfeld / in-medias-res.com" > <sch...@in...> wrote: >> In fact i don't see a concrete reason to open it up. You can leave it >> like it is, BUT (a big but!) then you really should do the moderation >> properly. For example: I've written a mail to the -dev list about >> database upgrade procedure on 24th november, which were quiet important >> for me this time, to can have a new mantis version packaged in Debian at >> all. It never entered the mailing list (I've recently rechecked the >> archives). > Doing things manually is always errore prone... My preferred option is > still: no moderation, but posts allowed only from subscribers. Well it isn't that hard to moderate entries in a proper mailinglist system ;-) So moderating non-subcribed mails in a regular manner is okay and really should be done. I repeat what i said in my first mail: You can *not* expect, that everyone who might be partially involved in mantis / debian packages (e.g. security members) has the mantis list subscribed. > CVE numbers are there for a reason: they should be ALWAYS referenced > in the bug summary Well yeah. Didn't think about it. But if that were done in the past, association (for me) would have been possible. It wasn't. So there is nothing to argue about this. >> a) Split Category in sub-categories like you said (makes association easier) >> b) Take some time to describe the problem and a solution which is >> reproducible. Cause if i maintain mantis/stable in Debian it does not >> help me much if you fix bugs in a devel/instable version. I need to know >> how I can implement your fixes in the stable version. > +1. > The best IMHO would be a point release as soon as the security problem is fixed Yes that would be the *best*. But it would be enough (for distribution developers/packagers, but eventually not for 'ordinary users') to provide patches or at least descriptions. > >> But in case of mantis I had to replace the RSS api, >> cause it is to be considered non-free (e.g. with this RSS api mantis can >> *not* be used in companies without doing something against the law!). > AARGH! I did not realized this before :( > I have to do the same for Fedora, or the package can be removed from the repo. > > Can you consider using another one without the commercial use restriction? Have a look at my debian packages. I did replace RSS functions in there with another RSS api (unfortunately comments in it are french, but the code is quiet self explanatory). The only problem with the API I've used is, that it seems not to be able to support everything the one shipped with mantis does. But i haven't noticed a notable change between mantis+orig and mantis+dfsg (which is the debian version). It would be *really* great if mantis developers could replace the RSS API by a free for commercial use API. Yet, it is impossible to use it unmodified and legal in companies, as I said. >> But yeah: It would be a good idea to provide patches. At least for your >> current stable version. I'm pretty sure that would make users of >> mantis/stable (without using distribution packages) a lot of happier, >> too. Cause now it seems as if you would fix security bugs only in your >> developer versions. > Not really true. AFAICT security bugs are fixed _first_ in the > development version, but they are usually cloned for the latest stable > release and fixed also there (see also the CVS branch for 1.0.x > releases. So they are fixed in the CVS version? It would help if someone would publish that somewhere. But there hasn't been any updated released for some recent flaws (at least for CVE-2006-6574) > We probalby have to make sure ALL security issues have duoble entries > for release/devel branches I don't understand that statement. >> Apart from this: It would be great if you could just let an SQL file >> exist (apart from install.php) for the upgrade job. AFAIR you did have >> such an SQL file earlier and that is at all the best you can give to >> packagers (at least for me @ debian). > I am working on the updgrade topic (see bug 7663). Would you like to > help me on that? Hmm. I would prefer to have .sql files for upgrading. Thats because i use a common framework (dbconfig-common) for the debian packages to do SQL stuff, like database creation etc. That does ease updates a lot, if you do have sql files as it does handle this itself (you have specific sql scripts for specific version-jumps and it does pick the right one itself). Also i don't like to have depends on interpreters, if I only need them for install/upgrade. In my sense this is ugly. I created sql files myself by doing upgrade manually and let the upgrader print the SQL statements (similar for the install). That worked well for 0.19.x to 1.0.6 with a problematic environment (non-english, german localized) but anyway: For further packaging, that is a workaround, not a solution. I don't know if i could lend you a hand. Do you something I can do for your help? |
From: Gianluca S. <gi...@gm...> - 2007-01-17 15:18:32
|
T24gMS8xNy8wNywgInNjaMO2bmZlbGQgLyBpbi1tZWRpYXMtcmVzLmNvbSIKPHNjaG9lbmZlbGRA aW4tbWVkaWFzLXJlcy5jb20+IHdyb3RlOgo+ID4+IEJ1dCBpbiBjYXNlIG9mIG1hbnRpcyBJIGhh ZCB0byByZXBsYWNlIHRoZSBSU1MgYXBpLAo+ID4+IGNhdXNlIGl0IGlzIHRvIGJlIGNvbnNpZGVy ZWQgbm9uLWZyZWUgKGUuZy4gd2l0aCB0aGlzIFJTUyBhcGkgbWFudGlzIGNhbgo+ID4+ICpub3Qq IGJlIHVzZWQgaW4gY29tcGFuaWVzIHdpdGhvdXQgZG9pbmcgc29tZXRoaW5nIGFnYWluc3QgdGhl IGxhdyEpLgo+ID4gQUFSR0ghIEkgZGlkIG5vdCByZWFsaXplZCB0aGlzIGJlZm9yZSA6KAo+ID4g SSBoYXZlIHRvIGRvIHRoZSBzYW1lIGZvciBGZWRvcmEsIG9yIHRoZSBwYWNrYWdlIGNhbiBiZSBy ZW1vdmVkIGZyb20gdGhlIHJlcG8uCj4gPgo+ID4gQ2FuIHlvdSBjb25zaWRlciB1c2luZyBhbm90 aGVyIG9uZSB3aXRob3V0IHRoZSBjb21tZXJjaWFsIHVzZSByZXN0cmljdGlvbj8KPgo+IEhhdmUg YSBsb29rIGF0IG15IGRlYmlhbiBwYWNrYWdlcy4gSSBkaWQgcmVwbGFjZSBSU1MgZnVuY3Rpb25z IGluIHRoZXJlCj4gd2l0aCBhbm90aGVyIFJTUyBhcGkgKHVuZm9ydHVuYXRlbHkgY29tbWVudHMg aW4gaXQgYXJlIGZyZW5jaCwgYnV0IHRoZQo+IGNvZGUgaXMgcXVpZXQgc2VsZiBleHBsYW5hdG9y eSkuIFRoZSBvbmx5IHByb2JsZW0gd2l0aCB0aGUgQVBJIEkndmUgdXNlZAo+IGlzLCB0aGF0IGl0 IHNlZW1zIG5vdCB0byBiZSBhYmxlIHRvIHN1cHBvcnQgZXZlcnl0aGluZyB0aGUgb25lIHNoaXBw ZWQKPiB3aXRoIG1hbnRpcyBkb2VzLiBCdXQgaSBoYXZlbid0IG5vdGljZWQgYSBub3RhYmxlIGNo YW5nZSBiZXR3ZWVuCj4gbWFudGlzK29yaWcgYW5kIG1hbnRpcytkZnNnICh3aGljaCBpcyB0aGUg ZGViaWFuIHZlcnNpb24pLgo+Cj4gSXQgd291bGQgYmUgKnJlYWxseSogZ3JlYXQgaWYgbWFudGlz IGRldmVsb3BlcnMgY291bGQgcmVwbGFjZSB0aGUgUlNTCj4gQVBJIGJ5IGEgZnJlZSBmb3IgY29t bWVyY2lhbCB1c2UgQVBJLgoKKzEwCgo+ID4gTm90IHJlYWxseSB0cnVlLiBBRkFJQ1Qgc2VjdXJp dHkgYnVncyBhcmUgZml4ZWQgX2ZpcnN0XyBpbiB0aGUKPiA+IGRldmVsb3BtZW50IHZlcnNpb24s IGJ1dCB0aGV5IGFyZSB1c3VhbGx5IGNsb25lZCBmb3IgdGhlIGxhdGVzdCBzdGFibGUKPiA+IHJl bGVhc2UgYW5kIGZpeGVkIGFsc28gdGhlcmUgKHNlZSBhbHNvIHRoZSBDVlMgYnJhbmNoIGZvciAx LjAueAo+ID4gcmVsZWFzZXMuCj4KPiBTbyB0aGV5IGFyZSBmaXhlZCBpbiB0aGUgQ1ZTIHZlcnNp b24/IEl0IHdvdWxkIGhlbHAgaWYgc29tZW9uZSB3b3VsZAo+IHB1Ymxpc2ggdGhhdCBzb21ld2hl cmUuIEJ1dCB0aGVyZSBoYXNuJ3QgYmVlbiBhbnkgdXBkYXRlZCByZWxlYXNlZCBmb3IKPiBzb21l IHJlY2VudCBmbGF3cyAoYXQgbGVhc3QgZm9yIENWRS0yMDA2LTY1NzQpCkFGQUlLLCB5ZXMuIFNl ZToKaHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0y MTk5MzcKYW5kIG15IHBhdGNoIGluOgpodHRwOi8vY3ZzLmZlZG9yYS5yZWRoYXQuY29tL3ZpZXdj dnMvcnBtcy9tYW50aXMvRkMtNi8/cm9vdD1leHRyYXMKCj4KPiA+IFdlIHByb2JhbGJ5IGhhdmUg dG8gbWFrZSBzdXJlIEFMTCBzZWN1cml0eSBpc3N1ZXMgaGF2ZSBkdW9ibGUgZW50cmllcwo+ID4g Zm9yIHJlbGVhc2UvZGV2ZWwgYnJhbmNoZXMKPgo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGF0IHN0 YXRlbWVudC4KCkknbGwgdHJ5IHRvIGJlIG1vcmUgdmVyYm9zZS4gSSB0aGluayB3ZSBzaG91bGQg aGF2ZSwgZm9yIGVhY2ggc2VjdXJpdHkKYnVnLCB0d28gYWN0dWFsIGlzc3VlcyByZXBvcnRlZC4g VGhleSBjb250YWlucyB0aGUgc2FtZSBpbmZvLCBidXQgb25lCmlzIHJlcG9ydGVkIGFnYWluc3Qg ZGV2ZWwsIHRoZSBvdGhlciBhZ2FpbnN0IHRoZSBsYXN0IHJlbGFzZWQgdmVyc2lvbiwKb3RoZXJ3 aXNlIHlvdSBuZXZlciBrbm93IGhvdyBpcyB0aGUgc2VjdXJpdHkgc3RhdHVzIG9mIGJvdGguClRo aXMgc2VlbXMgdG8gYmUgbW9yZSBvciBsZXNzIGFuIGFscmVhZHkgdXNlZCBzY2hlbWU7IHdlIHNo b3VsZCBqdXN0Cm1ha2Ugc3VyZSBhbGwgc2VjdXJpdHkgaXNzdWVzIGFyZSByZXBvcnRlZCB0aGlz IHdheS4KCj4KPiA+PiBBcGFydCBmcm9tIHRoaXM6IEl0IHdvdWxkIGJlIGdyZWF0IGlmIHlvdSBj b3VsZCBqdXN0IGxldCBhbiBTUUwgZmlsZQo+ID4+IGV4aXN0IChhcGFydCBmcm9tIGluc3RhbGwu cGhwKSBmb3IgdGhlIHVwZ3JhZGUgam9iLiBBRkFJUiB5b3UgZGlkIGhhdmUKPiA+PiBzdWNoIGFu IFNRTCBmaWxlIGVhcmxpZXIgYW5kIHRoYXQgaXMgYXQgYWxsIHRoZSBiZXN0IHlvdSBjYW4gZ2l2 ZSB0bwo+ID4+IHBhY2thZ2VycyAoYXQgbGVhc3QgZm9yIG1lIEAgZGViaWFuKS4KPiA+IEkgYW0g d29ya2luZyBvbiB0aGUgdXBkZ3JhZGUgdG9waWMgKHNlZSBidWcgNzY2MykuIFdvdWxkIHlvdSBs aWtlIHRvCj4gPiBoZWxwIG1lIG9uIHRoYXQ/Cj4KPiBIbW0uIEkgd291bGQgcHJlZmVyIHRvIGhh dmUgLnNxbCBmaWxlcyBmb3IgdXBncmFkaW5nLiBUaGF0cyBiZWNhdXNlIGkKPiB1c2UgYSBjb21t b24gZnJhbWV3b3JrIChkYmNvbmZpZy1jb21tb24pIGZvciB0aGUgZGViaWFuIHBhY2thZ2VzIHRv IGRvCj4gU1FMIHN0dWZmLCBsaWtlIGRhdGFiYXNlIGNyZWF0aW9uIGV0Yy4gVGhhdCBkb2VzIGVh c2UgdXBkYXRlcyBhIGxvdCwgaWYKPiB5b3UgZG8gaGF2ZSBzcWwgZmlsZXMgYXMgaXQgZG9lcyBo YW5kbGUgdGhpcyBpdHNlbGYgKHlvdSBoYXZlIHNwZWNpZmljCj4gc3FsIHNjcmlwdHMgZm9yIHNw ZWNpZmljIHZlcnNpb24tanVtcHMgYW5kIGl0IGRvZXMgcGljayB0aGUgcmlnaHQgb25lCj4gaXRz ZWxmKS4KSSBhbSBub3Qgc3VyZSB3aHkgaXQgaXMgaW1wbGVtZW50ZWQgdGhhdCB3YXksIG5vciBp ZiBzdWNoIGEgY2hhbmdlCmNvdWxkIGJlIGV2YWx1YXRlZDogVmljdG9yPwoKPiBBbHNvIGkgZG9u J3QgbGlrZSB0byBoYXZlIGRlcGVuZHMgb24gaW50ZXJwcmV0ZXJzLCBpZiBJIG9ubHkKPiBuZWVk IHRoZW0gZm9yIGluc3RhbGwvdXBncmFkZS4gSW4gbXkgc2Vuc2UgdGhpcyBpcyB1Z2x5LgpXZWxs Li4uIHlvdSBhbHJlYWR5IG5lZWQgcGhwIGZvciB1c2luZyBtYW50aXMuLi4KCgo+IEkgY3JlYXRl ZCBzcWwgZmlsZXMgbXlzZWxmIGJ5IGRvaW5nIHVwZ3JhZGUgbWFudWFsbHkgYW5kIGxldCB0aGUK PiB1cGdyYWRlciBwcmludCB0aGUgU1FMIHN0YXRlbWVudHMgKHNpbWlsYXIgZm9yIHRoZSBpbnN0 YWxsKS4gVGhhdCB3b3JrZWQKPiB3ZWxsIGZvciAwLjE5LnggdG8gMS4wLjYgd2l0aCBhIHByb2Js ZW1hdGljIGVudmlyb25tZW50IChub24tZW5nbGlzaCwKPiBnZXJtYW4gbG9jYWxpemVkKSBidXQg YW55d2F5OiBGb3IgZnVydGhlciBwYWNrYWdpbmcsIHRoYXQgaXMgYQo+IHdvcmthcm91bmQsIG5v dCBhIHNvbHV0aW9uLgphZ3JlZWQsIG5vdCBhIHNvbHV0aW9uIGJ1dCBpdCdzIGEgc21hcnQgdHJp Y2sgOikKCj4gSSBkb24ndCBrbm93IGlmIGkgY291bGQgbGVuZCB5b3UgYSBoYW5kLiBEbwo+IHlv dSBzb21ldGhpbmcgSSBjYW4gZG8gZm9yIHlvdXIgaGVscD8KSWYgYW55dGhpbmcsIHRlc3QgdGhl IHNjcmlwdCBvbiB5b3VyIG93biBpbnN0YWxsYXRpb24uIEknbSB0cnlpbmcgdG8KZmluZCB0aW1l IGZvciBmaW5pc2hpbmcgaXQsIGJ1dCB3b3JrK2ZhbWlseSthbGwgdGhlIHJlc3Qgc28gZmFyIGhh dmUKcHJldmFpbGVkLi4uCg== |
From:
<sch...@in...> - 2007-01-17 15:50:51
|
Gianluca Sforna wrote: >>> We probalby have to make sure ALL security issues have duoble entries >>> for release/devel branches >> I don't understand that statement. > > I'll try to be more verbose. I think we should have, for each security > bug, two actual issues reported. They contains the same info, but one > is reported against devel, the other against the last relased version, > otherwise you never know how is the security status of both. > This seems to be more or less an already used scheme; we should just > make sure all security issues are reported this way. Yes, i acknowledge. So basically we want this: - a bugreport for every security issue AND every version (strict!) - a fixed version in every branch if there is a solution for a security issue OR at least a patch for every branch - No hiding of security issues. Inform about cause and effect, as well as solution public and prominent. Do you agree? If so, then my question is: Victor what do you think about this? Is this possible? >> Also i don't like to have depends on interpreters, if I only >> need them for install/upgrade. In my sense this is ugly. > Well... you already need php for using mantis... Haha, funny. Well acutally yeah. But i don't need it twice! Most people i know (aswell as myself) do use libapacheX-mod-phpX. It does not need a CLI variant of php to run. A php-script as a shell script does need such a cli-variant. Therefore you require it to exist, additional to the module version. That does not make sense and is what i dislike. >> I created sql files myself by doing upgrade manually and let the >> upgrader print the SQL statements (similar for the install). That worked >> well for 0.19.x to 1.0.6 with a problematic environment (non-english, >> german localized) but anyway: For further packaging, that is a >> workaround, not a solution. > agreed, not a solution but it's a smart trick :) Thanks :-) >> I don't know if i could lend you a hand. Do >> you something I can do for your help? > If anything, test the script on your own installation. I'm trying to > find time for finishing it, but work+family+all the rest so far have > prevailed... Well as i said, i dislike the way how you do it (but I think that it may be the best solution at current!). But if i find the time to integrate it into my packages as a test, then i will give you some informations. |
From: Gianluca S. <gi...@gm...> - 2007-01-17 16:12:08
|
T24gMS8xNy8wNywgInNjaMO2bmZlbGQgLyBpbi1tZWRpYXMtcmVzLmNvbSIKPHNjaG9lbmZlbGRA aW4tbWVkaWFzLXJlcy5jb20+IHdyb3RlOgo+IFllcywgaSBhY2tub3dsZWRnZS4gU28gYmFzaWNh bGx5IHdlIHdhbnQgdGhpczoKPiAtIGEgYnVncmVwb3J0IGZvciBldmVyeSBzZWN1cml0eSBpc3N1 ZSBBTkQgZXZlcnkgdmVyc2lvbiAoc3RyaWN0ISkKKzEKPiAtIGEgZml4ZWQgdmVyc2lvbiBpbiBl dmVyeSBicmFuY2ggaWYgdGhlcmUgaXMgYSBzb2x1dGlvbiBmb3IgYSBzZWN1cml0eQo+IGlzc3Vl IE9SIGF0IGxlYXN0IGEgcGF0Y2ggZm9yIGV2ZXJ5IGJyYW5jaAorMSAodGhvdWdoIEkgZG9uJ3Qg dGhpbmsgaXQncyBzdHJpY3RseSBuZWNlc3NhcnkgZm9yIC1kZXZlbCkKCj4gLSBObyBoaWRpbmcg b2Ygc2VjdXJpdHkgaXNzdWVzLiBJbmZvcm0gYWJvdXQgY2F1c2UgYW5kIGVmZmVjdCwgYXMgd2Vs bAo+IGFzIHNvbHV0aW9uIHB1YmxpYyBhbmQgcHJvbWluZW50LgorMSAob3IsIGF0IGxlYXN0LCBy ZW1vdmUgdGhlIHByaXZhdGUgc3RhdHVzIG9uY2UgZml4ZWQpCgo+Cj4gPj4gSSBkb24ndCBrbm93 IGlmIGkgY291bGQgbGVuZCB5b3UgYSBoYW5kLiBEbwo+ID4+IHlvdSBzb21ldGhpbmcgSSBjYW4g ZG8gZm9yIHlvdXIgaGVscD8KPiA+IElmIGFueXRoaW5nLCB0ZXN0IHRoZSBzY3JpcHQgb24geW91 ciBvd24gaW5zdGFsbGF0aW9uLiBJJ20gdHJ5aW5nIHRvCj4gPiBmaW5kIHRpbWUgZm9yIGZpbmlz aGluZyBpdCwgYnV0IHdvcmsrZmFtaWx5K2FsbCB0aGUgcmVzdCBzbyBmYXIgaGF2ZQo+ID4gcHJl dmFpbGVkLi4uCj4KPiBXZWxsIGFzIGkgc2FpZCwgaSBkaXNsaWtlIHRoZSB3YXkgaG93IHlvdSBk byBpdCAoYnV0IEkgdGhpbmsgdGhhdCBpdCBtYXkKPiBiZSB0aGUgYmVzdCBzb2x1dGlvbiBhdCBj dXJyZW50ISkuIEJ1dCBpZiBpIGZpbmQgdGhlIHRpbWUgdG8gaW50ZWdyYXRlCj4gaXQgaW50byBt eSBwYWNrYWdlcyBhcyBhIHRlc3QsIHRoZW4gaSB3aWxsIGdpdmUgeW91IHNvbWUgaW5mb3JtYXRp b25zLgpUaGFua3MuIFZlcnkgbXVjaCBhcHByZWNpYXRlZAo= |
From: Richards, P. <pl...@la...> - 2007-01-18 09:24:01
|
Ik5vIGhpZGluZyBvZiBzZWN1cml0eSBpc3N1ZXMuIEluZm9ybSBhYm91dCBjYXVzZSBhbmQgZWZm ZWN0Ig0KDQpJc24ndCBwYXJ0IG9mIHRoZSBwcm9ibGVtIHRoYXQgd2UndmUgcHJldmlvdXNseSBt YXJrZWQgYW4gaXNzdWUgYXMgJ3ByaXZhdGUnIHVudGlsIGl0IGhhcyBiZWVuIGZpeGVkIChwaHAv TWljcm9zb2Z0L3dob2V2ZXIgZWxzZSBzZWVtIHRvIGRvIHRoaXMgYXMgJ3N0YW5kYXJkJykgYnV0 IHRoZW4gd2UndmUgbm90IG5lY2Vzc2FyaWx5IGFubm91bmNlZCBvciBtYWRlIHB1YmxpYyB0aGUg YnVnIHJlcG9ydCAqb25jZSBhIGZpeGVkIHZlcnNpb24gaGFzIGJlZW4gcmVsZWFzZWQqPw0KDQpp LmUuOg0KDQoxLiByZXNlYXJjaGVyIHJlcG9ydHMgYSBzZWN1cml0eSBpc3N1ZQ0KMi4gYnVnIHNo b3VsZCBiZSBtYXJrZWQgcHJpdmF0ZQ0KMy4gbWFudGlzIGZpeGVzIHRoZSBidWcgaW4gQ1ZTLCBh bmQgbWFrZXMgYSBuZXcgcmVsZWFzZSAodGhlc2Ugc2hvdWxkIGhhcHBlbiBhdCB0aGUgc2FtZSB0 aW1lIGluIG15IG9waW5pb24NCjQuIHJlbGVhc2UgYW5ub3VuY2VtZW50IGlzIG1hZGUgKyBidWcg aXMgbWFya2VkIGFzIHB1YmxpYy4NCg0KDQpQYXVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBtYW50aXNidC1kZXYtYm91bmNlc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21h aWx0bzptYW50aXNidC1kZXYtYm91bmNlc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXRdIE9uIEJlaGFs ZiBPZiAic2Now7ZuZmVsZCAvIGluLW1lZGlhcy1yZXMuY29tIg0KU2VudDogMTcgSmFudWFyeSAy MDA3IDE1OjUxDQpUbzogZGV2ZWxvcGVyIGRpc2N1c3Npb25zDQpTdWJqZWN0OiBSZTogW01hbnRp c2J0LWRldl0gbWFudGlzIHNlY3VyaXR5IHZzLiBkZWJpYW4gc2VjdXJpdHkNCg0KR2lhbmx1Y2Eg U2Zvcm5hIHdyb3RlOg0KPj4+IFdlIHByb2JhbGJ5IGhhdmUgdG8gbWFrZSBzdXJlIEFMTCBzZWN1 cml0eSBpc3N1ZXMgaGF2ZSBkdW9ibGUgZW50cmllcw0KPj4+IGZvciByZWxlYXNlL2RldmVsIGJy YW5jaGVzDQo+PiBJIGRvbid0IHVuZGVyc3RhbmQgdGhhdCBzdGF0ZW1lbnQuDQo+IA0KPiBJJ2xs IHRyeSB0byBiZSBtb3JlIHZlcmJvc2UuIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUsIGZvciBlYWNo IHNlY3VyaXR5DQo+IGJ1ZywgdHdvIGFjdHVhbCBpc3N1ZXMgcmVwb3J0ZWQuIFRoZXkgY29udGFp bnMgdGhlIHNhbWUgaW5mbywgYnV0IG9uZQ0KPiBpcyByZXBvcnRlZCBhZ2FpbnN0IGRldmVsLCB0 aGUgb3RoZXIgYWdhaW5zdCB0aGUgbGFzdCByZWxhc2VkIHZlcnNpb24sDQo+IG90aGVyd2lzZSB5 b3UgbmV2ZXIga25vdyBob3cgaXMgdGhlIHNlY3VyaXR5IHN0YXR1cyBvZiBib3RoLg0KPiBUaGlz IHNlZW1zIHRvIGJlIG1vcmUgb3IgbGVzcyBhbiBhbHJlYWR5IHVzZWQgc2NoZW1lOyB3ZSBzaG91 bGQganVzdA0KPiBtYWtlIHN1cmUgYWxsIHNlY3VyaXR5IGlzc3VlcyBhcmUgcmVwb3J0ZWQgdGhp cyB3YXkuDQoNClllcywgaSBhY2tub3dsZWRnZS4gU28gYmFzaWNhbGx5IHdlIHdhbnQgdGhpczoN Ci0gYSBidWdyZXBvcnQgZm9yIGV2ZXJ5IHNlY3VyaXR5IGlzc3VlIEFORCBldmVyeSB2ZXJzaW9u IChzdHJpY3QhKQ0KLSBhIGZpeGVkIHZlcnNpb24gaW4gZXZlcnkgYnJhbmNoIGlmIHRoZXJlIGlz IGEgc29sdXRpb24gZm9yIGEgc2VjdXJpdHkNCmlzc3VlIE9SIGF0IGxlYXN0IGEgcGF0Y2ggZm9y IGV2ZXJ5IGJyYW5jaA0KLSBObyBoaWRpbmcgb2Ygc2VjdXJpdHkgaXNzdWVzLiBJbmZvcm0gYWJv dXQgY2F1c2UgYW5kIGVmZmVjdCwgYXMgd2VsbA0KYXMgc29sdXRpb24gcHVibGljIGFuZCBwcm9t aW5lbnQuDQo= |
From: Gianluca S. <gi...@gm...> - 2007-01-18 09:28:31
|
On 1/18/07, Richards, Paul <pl...@la...> wrote: > > 1. researcher reports a security issue > 2. bug should be marked private > 3. mantis fixes the bug in CVS, and makes a new release (these should happen at the same time in my opinion > 4. release announcement is made + bug is marked as public. +1 for me. To be probably formalized on the wiki |
From:
<sch...@in...> - 2007-01-18 09:45:19
|
Hi, Richards, Paul wrote: > "No hiding of security issues. Inform about cause and effect" > > Isn't part of the problem that we've previously marked an issue as 'private' until it has been fixed Yes this is part of the problem. > [ .. others do this, too .. ] Yes, they do. Because they think that is a shame that they have security bugs. While this might be true for a commercial project, i think it is wrong for an open source project. Yes, by publishing security bugs before there is a solution there is a danger, that one might exploit it. But thats not a good reason to make a secret of it, cause this danger is there as long as a security bug is fixed, regardless of weather it is public or not. > not announced or made public the bug report *once a fixed version has > been released* Yes, that makes it even worse. > i.e.: > > 1. researcher reports a security issue > 2. bug should be marked private No. The reason for this is simple: If you make it private, then the only persons who can fix it, are the mantis developers. Why waste energy? Users and Packagers could provide help and patches. They don't have a chance, when you mark bugs private. So you artificially lengthen the duration until a security bug is fixed, instead of shortening it. Yes, there is pressure to fix security bugs if they are public. But that is good. Cause it is pressure to find a solution quickly. > 3. mantis fixes the bug in CVS, and makes a new release (these should happen at the same time in my opinion Yes, good. > 4. release announcement is made + bug is marked as public. Agree. > Paul Patrick > -----Original Message----- > From: man...@li... [mailto:man...@li...] On Behalf Of "schönfeld / in-medias-res.com" > Sent: 17 January 2007 15:51 > To: developer discussions > Subject: Re: [Mantisbt-dev] mantis security vs. debian security > > Gianluca Sforna wrote: >>>> We probalby have to make sure ALL security issues have duoble entries >>>> for release/devel branches >>> I don't understand that statement. >> I'll try to be more verbose. I think we should have, for each security >> bug, two actual issues reported. They contains the same info, but one >> is reported against devel, the other against the last relased version, >> otherwise you never know how is the security status of both. >> This seems to be more or less an already used scheme; we should just >> make sure all security issues are reported this way. > > Yes, i acknowledge. So basically we want this: > - a bugreport for every security issue AND every version (strict!) > - a fixed version in every branch if there is a solution for a security > issue OR at least a patch for every branch > - No hiding of security issues. Inform about cause and effect, as well > as solution public and prominent. > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev -- in medias res Gesellschaft für Kommunikationstechnologien mbH Dahlenerstr. 570 41239 Mönchengladbach tel. +49 (0) 2166 - 9999685 fax. +49 (0) 2166 - 9999800 email: sch...@in... |
From: Glenn H. <thr...@ma...> - 2007-01-18 20:41:19
|
On 18-Jan-07, at 4:23 AM, Richards, Paul wrote: > "No hiding of security issues. Inform about cause and effect" > > Isn't part of the problem that we've previously marked an issue as =20 > 'private' until it has been fixed (php/Microsoft/whoever else seem =20 > to do this as 'standard') but then we've not necessarily announced =20 > or made public the bug report *once a fixed version has been =20 > released*? I agree with this. Publishing the security bug BEFORE the fix is =20 available is irresponsible on our part. This would allow every script =20= kiddie on the planet to attack our listed installed base. > > i.e.: > > 1. researcher reports a security issue > 2. bug should be marked private > 3. mantis fixes the bug in CVS, and makes a new release (these =20 > should happen at the same time in my opinion > 4. release announcement is made + bug is marked as public. Part of the problem was that until recently, we didn't do step 4. =20 Security bugs were left hidden. I thing that making them public with =20 the release helps. As for the quality of the reports, we need to work on them. The =20 ones I have entered (and fixed) have had some links to the original =20 CVE, or equivalent pages. > > > Paul > > -----Original Message----- > From: man...@li... [mailto:mantisbt-=20 > dev...@li...] On Behalf Of "sch=F6nfeld / in-=20 > medias-res.com" > Sent: 17 January 2007 15:51 > To: developer discussions > Subject: Re: [Mantisbt-dev] mantis security vs. debian security > > Gianluca Sforna wrote: >>>> We probalby have to make sure ALL security issues have duoble =20 >>>> entries >>>> for release/devel branches >>> I don't understand that statement. >> >> I'll try to be more verbose. I think we should have, for each =20 >> security >> bug, two actual issues reported. They contains the same info, but one >> is reported against devel, the other against the last relased =20 >> version, >> otherwise you never know how is the security status of both. >> This seems to be more or less an already used scheme; we should just >> make sure all security issues are reported this way. > > Yes, i acknowledge. So basically we want this: > - a bugreport for every security issue AND every version (strict!) This has been our normal process for propagating bugs between =20 versions. The clones are usually prefixed with "Port". > - a fixed version in every branch if there is a solution for a =20 > security > issue OR at least a patch for every branch This isn't practical. The 0.18 stream is long dead. The code =20 structure has changed a lot and there's really no one to maintain it. =20= I believe that we are patching all security issues in the most recent =20= "stable" release and in the development stream. > - No hiding of security issues. Inform about cause and effect, as well > as solution public and prominent. ... Glenn --=20 Glenn Henshaw Logical Outcome Ltd. e: thr...@ma... w: www.logicaloutcome.ca Mantis developer and user |
From: Glenn H. <thr...@ma...> - 2007-01-18 20:44:24
|
On 17-Jan-07, at 8:20 AM, sch=F6nfeld / in-medias-res.com wrote: > > Hmm. I would prefer to have .sql files for upgrading. Thats because i > use a common framework (dbconfig-common) for the debian packages to do > SQL stuff, like database creation etc. That does ease updates a =20 > lot, if > you do have sql files as it does handle this itself (you have specific > sql scripts for specific version-jumps and it does pick the right one > itself). Also i don't like to have depends on interpreters, if I only > need them for install/upgrade. In my sense this is ugly. > I created sql files myself by doing upgrade manually and let the > upgrader print the SQL statements (similar for the install). That =20 > worked > well for 0.19.x to 1.0.6 with a problematic environment (non-english, > german localized) but anyway: For further packaging, that is a > workaround, not a solution. I don't know if i could lend you a =20 > hand. Do > you something I can do for your help? This is fine if the world resolved around MySQL. The adodb schema =20 approach we adopted in 1.x is an attempt to make the installation =20 work on all supported platforms. I think that we can use the same structure and build an un-=20 attended upgrader based on an existing configuration file. ... Glenn --=20 Glenn Henshaw Logical Outcome Ltd. e: thr...@ma... w: www.logicaloutcome.ca Mantis developer and user |