From metatracker at psf.upfronthosting.co.za Wed Jul 2 02:03:10 2008 From: metatracker at psf.upfronthosting.co.za (Frank Wierzbicki) Date: Wed, 02 Jul 2008 00:03:10 +0000 Subject: [Tracker-discuss] [issue212] Please give leosoto acess to make updates to the Jython issue tracker In-Reply-To: <1214956990.34.0.205400812906.issue212@psf.upfronthosting.co.za> Message-ID: <1214956990.34.0.205400812906.issue212@psf.upfronthosting.co.za> New submission from Frank Wierzbicki : Leo Soto is a new committer for Jython and needs to be able to edit/update/close issues. Thanks! ---------- messages: 1072 nosy: fwierzbicki priority: feature status: unread title: Please give leosoto acess to make updates to the Jython issue tracker topic: jython _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Jul 2 15:34:55 2008 From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda) Date: Wed, 02 Jul 2008 13:34:55 +0000 Subject: [Tracker-discuss] [issue212] Please give leosoto acess to make updates to the Jython issue tracker In-Reply-To: <1214956990.34.0.205400812906.issue212@psf.upfronthosting.co.za> Message-ID: <1215005695.43.0.34739457526.issue212@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Can you please confirm that the user name is "leosoto"? ---------- status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Jul 2 22:31:03 2008 From: metatracker at psf.upfronthosting.co.za (Leonardo Soto) Date: Wed, 02 Jul 2008 20:31:03 +0000 Subject: [Tracker-discuss] [issue212] Please give leosoto acess to make updates to the Jython issue tracker In-Reply-To: <1214956990.34.0.205400812906.issue212@psf.upfronthosting.co.za> Message-ID: <1215030663.92.0.22458694913.issue212@psf.upfronthosting.co.za> Leonardo Soto added the comment: Indeed, my username there is "leosoto" ---------- nosy: +leosoto _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Wed Jul 2 22:33:38 2008 From: metatracker at psf.upfronthosting.co.za (Raghuram Devarakonda) Date: Wed, 02 Jul 2008 20:33:38 +0000 Subject: [Tracker-discuss] [issue212] Please give leosoto acess to make updates to the Jython issue tracker In-Reply-To: <1214956990.34.0.205400812906.issue212@psf.upfronthosting.co.za> Message-ID: <1215030818.38.0.0621295158571.issue212@psf.upfronthosting.co.za> Raghuram Devarakonda added the comment: Done. ---------- status: chatting -> resolved _______________________________________________________ PSF Meta Tracker _______________________________________________________ From nnorwitz at gmail.com Fri Jul 11 07:46:42 2008 From: nnorwitz at gmail.com (Neal Norwitz) Date: Thu, 10 Jul 2008 22:46:42 -0700 Subject: [Tracker-discuss] private (non-public) bugs Message-ID: We are tracking some security issues that have been reported in Python. Ideally we would track these using the normal python bug tracker. However, since we can't make the information public yet, we'd need access to the bugs limited to a subset of people. I'm not sure how we would define that subset, perhaps just a static list, or the admins. Right now, the people that make the most sense are the developers on security at python.org (not sure if the list subscribers is public info though). If not, Barry can provide. Does this capability exist? If not, how hard would it be to add? n From martin at v.loewis.de Fri Jul 11 08:58:26 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 11 Jul 2008 08:58:26 +0200 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: References: Message-ID: <48770492.7080509@v.loewis.de> > Does this capability exist? If not, how hard would it be to add? It doesn't exist now. Adding it to the current tracker is difficult, since we currently give "read" permission to anonymous user in a declarative manner. This would need to be replaced with a per-issue permission check; the difficult part here is the testing that you haven't declared any permission elsewhere that still allows information to leak. If you want this implemented, please submit an issue in the meta tracker, and be prepared to test it thoroughly (perhaps even with a repeated automatic test, to avoid leaking information in case the tracker configuration is changed). Regards, Martin From barry at python.org Fri Jul 11 14:16:00 2008 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Jul 2008 08:16:00 -0400 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: <48770492.7080509@v.loewis.de> References: <48770492.7080509@v.loewis.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 11, 2008, at 2:58 AM, Martin v. L?wis wrote: >> Does this capability exist? If not, how hard would it be to add? > > It doesn't exist now. Adding it to the current tracker is difficult, > since we currently give "read" permission to anonymous user in a > declarative manner. This would need to be replaced with a per-issue > permission check; the difficult part here is the testing that you > haven't declared any permission elsewhere that still allows > information to leak. > > If you want this implemented, please submit an issue in the meta > tracker, and be prepared to test it thoroughly (perhaps even with > a repeated automatic test, to avoid leaking information in case > the tracker configuration is changed). We could use Launchpad for private and security issues. It's tracker is able to limit visibility (it has two switches which are related: private and security). There's already a Python team, mostly to claim the namespace, but it should be fairly easy to create a special psrt team and only give it permission to view security issues. Let me know if I should pursue this. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSHdPAHEjvBPtnXfVAQJlOwP9G0kBqX9FRTkRuVbXQ/i8Qi5sUQSv/khA mhvYNSLKUi2UluAkMJfcvKf0FjGWW3rN4A2IjvRQZL60hurgQCm5Pwzulxaqeqtx uUvQlsl0TQmdB/fT3l9e1ElM7wJ58fqsuTcRJNqNq9m0d4P+9Nm6CwQwGUGD8IHk qmaxKz09ihg= =i+N1 -----END PGP SIGNATURE----- From martin at v.loewis.de Fri Jul 11 23:16:37 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Fri, 11 Jul 2008 23:16:37 +0200 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: References: <48770492.7080509@v.loewis.de> Message-ID: <4877CDB5.2060502@v.loewis.de> > We could use Launchpad for private and security issues. If setting up a separate tracker is an option, it's fairly easy to set up another roundup instance which doesn't allow any anonymous access, and that doesn't allow web signup of new users. Regards, Martin From barry at python.org Fri Jul 11 23:35:01 2008 From: barry at python.org (Barry Warsaw) Date: Fri, 11 Jul 2008 17:35:01 -0400 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: <4877CDB5.2060502@v.loewis.de> References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 11, 2008, at 5:16 PM, Martin v. L?wis wrote: >> We could use Launchpad for private and security issues. > > If setting up a separate tracker is an option, it's fairly easy > to set up another roundup instance which doesn't allow any anonymous > access, and that doesn't allow web signup of new users. That would work for me. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSHfSBXEjvBPtnXfVAQJ8IQP+LHFGUeVSxTF1g5Jb8sG+eEQVw7jOURU2 lFdBPh+l5HIge2qY1SNb8LPNy8asb+xbBMCrl8LgxxuK7C2fKGjBfVRpJ74ZPC0E 1ivrTOhuV9VP37elPOkWka6ACdxrbDxG45nTcnoCZiiOzNeIs6JUNZukJjhYpegd sWAVVzxODjA= =NLnS -----END PGP SIGNATURE----- From metatracker at psf.upfronthosting.co.za Sat Jul 12 20:41:23 2008 From: metatracker at psf.upfronthosting.co.za (Brett C.) Date: Sat, 12 Jul 2008 18:41:23 +0000 Subject: [Tracker-discuss] [issue213] Searching for ``patch`` creates a recursion limit traceback In-Reply-To: <1215888083.41.0.0700519576577.issue213@psf.upfronthosting.co.za> Message-ID: <1215888083.41.0.0700519576577.issue213@psf.upfronthosting.co.za> New submission from Brett C. : As accidentally reported in the main tracker, if you search for ``patch``, you end up with a template error about recursion depth. I suspect too many issues have the word 'patch' in them and Python's own recursion limit is being hit (or something). Not sure if there is really anything we can do. ---------- messages: 1076 nosy: brett.cannon priority: bug status: unread title: Searching for ``patch`` creates a recursion limit traceback _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Sat Jul 12 22:04:58 2008 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 12 Jul 2008 20:04:58 +0000 Subject: [Tracker-discuss] [issue213] Searching for ``patch`` creates a recursion limit traceback In-Reply-To: <1215888083.41.0.0700519576577.issue213@psf.upfronthosting.co.za> Message-ID: <1215893098.18.0.374381567797.issue213@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now worked around this by setting max_stack_depth to 7000 in the postgres configuration. I think it would be better if roundup issued a different postgresql statement, although I'm not sure how that could look like. ---------- nosy: +loewis status: unread -> done-cbb _______________________________________________________ PSF Meta Tracker _______________________________________________________ From martin at v.loewis.de Sat Jul 12 23:22:00 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sat, 12 Jul 2008 23:22:00 +0200 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> Message-ID: <48792078.9000209@v.loewis.de> > That would work for me. Ok, I have created that tracker, as http://psf.upfronthosting.co.za/roundup/security Barry is Admin user, you should 1. invoke the password reset procedure 2. create a test issue, to verify that a) the issue gets announced to security at python.org (I can't, as I'm not member of that list) b) anonymous users have no way to get at the issue, individual messages or files 3. create any new users through the web interface. Users can't register themselves, so the admin has to create them. The schema is the same as in the Python tracker, so people should normally get the Developer role (unless you add users which should not be able to change status etc, and not show up in the assign-to list) If there are any problems, please let me know. Regards, Martin From barry at python.org Sat Jul 12 23:54:39 2008 From: barry at python.org (Barry Warsaw) Date: Sat, 12 Jul 2008 17:54:39 -0400 Subject: [Tracker-discuss] private (non-public) bugs In-Reply-To: <48792078.9000209@v.loewis.de> References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> Message-ID: <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 12, 2008, at 5:22 PM, Martin v. L?wis wrote: >> That would work for me. > > Ok, I have created that tracker, as > > http://psf.upfronthosting.co.za/roundup/security > > Barry is Admin user, you should > 1. invoke the password reset procedure > 2. create a test issue, to verify that > a) the issue gets announced to security at python.org > (I can't, as I'm not member of that list) Do you want to be? > b) anonymous users have no way to get at the issue, > individual messages or files The tracker appears to work, thanks Martin! I'm in, did a password reset, and created an issue. I could not get to the tracker as an anonymous user. The issue did show up on the security mailing list. Two quick problems I noticed: I can't assign an issue to Python 3.0, and it appears as though the priorities are different than the standard tracker. It would be great if they were the same. > 3. create any new users through the web interface. > Users can't register themselves, so the admin has > to create them. > The schema is the same as in the Python tracker, so > people should normally get the Developer role (unless > you add users which should not be able to change > status etc, and not show up in the assign-to list) I think anybody who has access to the security tracker should at least be a Developer, if not also an Admin. Security list members: if you want access, please let us know. I think we should use the meta tracker from now on for the security tracker too. Martin, this is great, thanks. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSHkoH3EjvBPtnXfVAQLXEgQAi1EAFps3HpgwmgUmvw1GpTDbFmXn0bxX xsRSyYcFYFF0zrk+ZrZ2jaDf9MP0SvgYexNI8+lfYZckuLk8FPzGYjMe6bwzmmm/ Go26rQjVcu+Kex4GCgTdkQTciE7+aUegch6Psz/m+0BVDSgGeH8m21BGHpYg9JaK o7xJpD6xY/w= =bqo0 -----END PGP SIGNATURE----- From metatracker at psf.upfronthosting.co.za Sun Jul 13 00:16:40 2008 From: metatracker at psf.upfronthosting.co.za (techtonik) Date: Sat, 12 Jul 2008 22:16:40 +0000 Subject: [Tracker-discuss] [issue213] Searching for ``patch`` creates a recursion limit traceback In-Reply-To: <1215888083.41.0.0700519576577.issue213@psf.upfronthosting.co.za> Message-ID: <1215901000.52.0.149364360975.issue213@psf.upfronthosting.co.za> techtonik added the comment: Error output is in attach in python bugtracker http://bugs.python.org/file10887/bugs.python.org.txt It has a title "Templating Error" and wonder if SQL result is stored in memory before output? In this case is it possible to modify templating engine to allow streaming content directly from DB query? ---------- nosy: +techtonik status: done-cbb -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From martin at v.loewis.de Sun Jul 13 01:06:37 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 13 Jul 2008 01:06:37 +0200 Subject: [Tracker-discuss] [issue213] Searching for ``patch`` creates a recursion limit traceback In-Reply-To: <1215901000.52.0.149364360975.issue213@psf.upfronthosting.co.za> References: <1215901000.52.0.149364360975.issue213@psf.upfronthosting.co.za> Message-ID: <487938FD.3060807@v.loewis.de> > It has a title "Templating Error" and wonder if SQL result is stored in memory > before output? In this case is it possible to modify templating engine to allow > streaming content directly from DB query? That's not the problem at all. If you look at the true exception, you'll notice self.db.cursor.execute(sql, tuple([int(row[0]) for row in r])) ProgrammingError: ERROR: stack depth limit exceeded HINT: Increase the configuration parameter "max_stack_depth". This is a true error from postgres, and has nothing to do with the template engine (and whether it's computing the result in memory). Apparently, Postgres cannot properly support an "in" clause with a large enumeration of literal values. It shows up as a templating error, because the query is (indirectly) invoked in the template, and because of the postgres exception, the template cannot be rendered. As I said, I worked around it by increasing postgresql's max_stack_depth, from 2MB (which it was) to 7MB (which is the recommended 1M less than `ulimit -s`). As I also said, this part of SQL usage should probably be rewritten. From metatracker at psf.upfronthosting.co.za Sun Jul 13 01:06:40 2008 From: metatracker at psf.upfronthosting.co.za (=?utf-8?q?Martin_v._L=C3=B6wis?=) Date: Sat, 12 Jul 2008 23:06:40 +0000 Subject: [Tracker-discuss] =?utf-8?q?=5Bissue213=5D_Searching_for_=60=60pa?= =?utf-8?q?tch=60=60_creates_a=09recursion_limit_traceback?= In-Reply-To: <1215901000.52.0.149364360975.issue213@psf.upfronthosting.co.za> Message-ID: <487938FD.3060807@v.loewis.de> Martin v. L?wis added the comment: > It has a title "Templating Error" and wonder if SQL result is stored in memory > before output? In this case is it possible to modify templating engine to allow > streaming content directly from DB query? That's not the problem at all. If you look at the true exception, you'll notice self.db.cursor.execute(sql, tuple([int(row[0]) for row in r])) ProgrammingError: ERROR: stack depth limit exceeded HINT: Increase the configuration parameter "max_stack_depth". This is a true error from postgres, and has nothing to do with the template engine (and whether it's computing the result in memory). Apparently, Postgres cannot properly support an "in" clause with a large enumeration of literal values. It shows up as a templating error, because the query is (indirectly) invoked in the template, and because of the postgres exception, the template cannot be rendered. As I said, I worked around it by increasing postgresql's max_stack_depth, from 2MB (which it was) to 7MB (which is the recommended 1M less than `ulimit -s`). As I also said, this part of SQL usage should probably be rewritten. ---------- title: Searching for ``patch`` creates a recursion limit traceback -> Searching for ``patch`` creates a recursion limit traceback _______________________________________________________ PSF Meta Tracker _______________________________________________________ From brett at python.org Sun Jul 13 20:23:05 2008 From: brett at python.org (Brett Cannon) Date: Sun, 13 Jul 2008 11:23:05 -0700 Subject: [Tracker-discuss] [PSRT] private (non-public) bugs In-Reply-To: <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> Message-ID: On Sat, Jul 12, 2008 at 2:54 PM, Barry Warsaw wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Jul 12, 2008, at 5:22 PM, Martin v. L?wis wrote: > >>> That would work for me. >> >> Ok, I have created that tracker, as >> >> http://psf.upfronthosting.co.za/roundup/security >> >> Barry is Admin user, you should >> 1. invoke the password reset procedure >> 2. create a test issue, to verify that >> a) the issue gets announced to security at python.org >> (I can't, as I'm not member of that list) > > Do you want to be? > >> b) anonymous users have no way to get at the issue, >> individual messages or files > > The tracker appears to work, thanks Martin! I'm in, did a password reset, > and created an issue. I could not get to the tracker as an anonymous user. > The issue did show up on the security mailing list. > > Two quick problems I noticed: I can't assign an issue to Python 3.0, and it > appears as though the priorities are different than the standard tracker. > It would be great if they were the same. > >> 3. create any new users through the web interface. >> Users can't register themselves, so the admin has >> to create them. >> The schema is the same as in the Python tracker, so >> people should normally get the Developer role (unless >> you add users which should not be able to change >> status etc, and not show up in the assign-to list) > > I think anybody who has access to the security tracker should at least be a > Developer, if not also an Admin. > > Security list members: if you want access, please let us know. I think we > should use the meta tracker from now on for the security tracker too. I'll take access. -Brett From stephen at xemacs.org Mon Jul 14 02:16:30 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 14 Jul 2008 09:16:30 +0900 Subject: [Tracker-discuss] [PSRT] private (non-public) bugs In-Reply-To: References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> Message-ID: <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> > On Sat, Jul 12, 2008 at 2:54 PM, Barry Warsaw wrote: > > Security list members: if you want access, please let us know. I think we > > should use the meta tracker from now on for the security tracker too. This is not a good idea, IMO. If there is a problem with access control in the security tracker, you don't want 3rd parties knowing about it. Ditto the main and meta trackers, for that matter. So I think you want somebody who knows about tracker security to vette tracker issues before they go to the public meta-tracker. From brett at python.org Mon Jul 14 02:58:23 2008 From: brett at python.org (Brett Cannon) Date: Sun, 13 Jul 2008 17:58:23 -0700 Subject: [Tracker-discuss] [PSRT] private (non-public) bugs In-Reply-To: <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: On Sun, Jul 13, 2008 at 5:16 PM, Stephen J. Turnbull wrote: > > On Sat, Jul 12, 2008 at 2:54 PM, Barry Warsaw wrote: > > > > Security list members: if you want access, please let us know. I think we > > > should use the meta tracker from now on for the security tracker too. > > This is not a good idea, IMO. If there is a problem with access > control in the security tracker, you don't want 3rd parties knowing > about it. Ditto the main and meta trackers, for that matter. > > So I think you want somebody who knows about tracker security to vette > tracker issues before they go to the public meta-tracker. So are you suggesting that ALL issues not go on the meta tracker, or only ones pertaining to access control issues? If it is the latter, I can understand, but for the former that is just not feasible. It would put too much of a burden on the infrastructure committee in general and Martin in particular. -Brett From stephen at xemacs.org Mon Jul 14 08:22:27 2008 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 14 Jul 2008 15:22:27 +0900 Subject: [Tracker-discuss] [PSRT] private (non-public) bugs In-Reply-To: References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <87lk0556jg.fsf@uwakimon.sk.tsukuba.ac.jp> Brett Cannon writes: > On Sun, Jul 13, 2008 at 5:16 PM, Stephen J. Turnbull wrote: > > So I think you want somebody who knows about tracker security to vette > > tracker issues before they go to the public meta-tracker. > > So are you suggesting that ALL issues not go on the meta tracker, or > only ones pertaining to access control issues? Idneed, I'm suggesting that all non-feature-request issues go on the security tracker. I'm not very serious about that, but with security I believe you should start your planning with a conservative stance and then start accepting low-risk flaws that would cost a lot to fix. OTOH, the "everything on the meta-tracker" approach raised a red flag, for sure. Note that "security issues in the tracker" includes anything that generates a traceback in the user's browser, not just obvious access control issues. From barry at python.org Wed Jul 16 02:34:38 2008 From: barry at python.org (Barry Warsaw) Date: Tue, 15 Jul 2008 20:34:38 -0400 Subject: [Tracker-discuss] [PSRT] private (non-public) bugs In-Reply-To: <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <48770492.7080509@v.loewis.de> <4877CDB5.2060502@v.loewis.de> <48792078.9000209@v.loewis.de> <1E59AB64-FCB5-4EE7-ABD1-F3F328AA9723@python.org> <87mykl5nhd.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 13, 2008, at 8:16 PM, Stephen J. Turnbull wrote: >> On Sat, Jul 12, 2008 at 2:54 PM, Barry Warsaw >> wrote: > >>> Security list members: if you want access, please let us know. I >>> think we >>> should use the meta tracker from now on for the security tracker >>> too. > > This is not a good idea, IMO. If there is a problem with access > control in the security tracker, you don't want 3rd parties knowing > about it. Ditto the main and meta trackers, for that matter. > > So I think you want somebody who knows about tracker security to vette > tracker issues before they go to the public meta-tracker. I'm fine with just discussion security tracker issues on these mailing lists. One problem: tracker-discuss archives are public. Perhaps we should make it private? (I can't see any reason it has to be public.) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSH1CHnEjvBPtnXfVAQLHtwQAlLWwvg09BpNtwF3dirOawhoBeRNowIZg VwLy73Atc6EYKwDwyBA28+DEdY6bHsQObeBCAYyq1cKoIunwteYfw+Fjm6CiHk3k pj5PIQM3zGMMFrgwXbVCH3YrtNHHjWx/z6eifiVhiBRu58/qy0LT05KDjzY4Xdux gaN66nMBAfg= =8WnP -----END PGP SIGNATURE----- From skip at pobox.com Sun Jul 27 15:58:13 2008 From: skip at pobox.com (skip at pobox.com) Date: Sun, 27 Jul 2008 08:58:13 -0500 Subject: [Tracker-discuss] Suggested change to spambayes detector Message-ID: <18572.32501.418370.325227@montanaro-dyndns-org.local> In looking at the code for the spambayes detector I noticed that the raw author age is used as a token: authorage = nodets - db.getnode('user', authorid)['creation'].timestamp() tokens = ["klass:%s" % klass.classname, "author:%s" % authorid, "authorage:%d" % int(authorage)] Large numeric values work better as tokens if you can place them into buckets, otherwise essentially every authorage:NNN token will be unique. The easiest way to do this is to take the log of the value. See the attached patch. Skip -------------- next part -------------- Index: detectors/spambayes.py =================================================================== --- detectors/spambayes.py (revision 61012) +++ detectors/spambayes.py (working copy) @@ -2,6 +2,7 @@ import xmlrpclib import socket import time +import math from roundup.exceptions import Reject @@ -27,7 +28,7 @@ tokens = ["klass:%s" % klass.classname, "author:%s" % authorid, - "authorage:%d" % int(authorage)] + "authorage:%d" % int(math.log(authorage))] return (content, tokens) From martin at v.loewis.de Sun Jul 27 19:57:26 2008 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 27 Jul 2008 19:57:26 +0200 Subject: [Tracker-discuss] Suggested change to spambayes detector In-Reply-To: <18572.32501.418370.325227@montanaro-dyndns-org.local> References: <18572.32501.418370.325227@montanaro-dyndns-org.local> Message-ID: <488CB706.2070801@v.loewis.de> > Large numeric values work better as tokens if you can place them into > buckets, otherwise essentially every authorage:NNN token will be unique. > The easiest way to do this is to take the log of the value. See the > attached patch. Thanks for the suggestion; I have now installed that change. Regards, Martin