From ganesh1238 at iiitd.ac.in Wed Jun 12 06:05:55 2013 From: ganesh1238 at iiitd.ac.in (Ganesh Ghongane) Date: Wed, 12 Jun 2013 09:35:55 +0530 Subject: [Tracker-discuss] Fwd: Survey on Integrating Issue tracking system with community based Q&A website In-Reply-To: References: Message-ID: Hello, We are conducting a survey to find out impact of Q&A based website such as https://www.stackoverflow.com in issue resolving process. Please help us and contribute in our research by filling this survey. It will not take more than 5 minutes of your precious time. Send it also to your colleagues which are in same profession. The link to the survey is- http://www.surveymonkey.com/s/7T8C3DL *Thanks & Regards Ganesh Ghongane MT12038 IIIT-Delhi,New Delhi, India* -------------- next part -------------- An HTML attachment was scrubbed... URL: From roundup-admin at psf.upfronthosting.co.za Thu Jun 13 03:26:08 2013 From: roundup-admin at psf.upfronthosting.co.za (Python tracker) Date: Thu, 13 Jun 2013 01:26:08 +0000 Subject: [Tracker-discuss] Failed issue tracker submission Message-ID: <20130613012608.6BDB956A26@psf.upfronthosting.co.za> The node specified by the designator in the subject of your message ("281857369") does not exist. Subject was: "[issue281857369]" Mail Gateway Help ================= Incoming messages are examined for multiple parts: . In a multipart/mixed message or part, each subpart is extracted and examined. The text/plain subparts are assembled to form the textual body of the message, to be stored in the file associated with a "msg" class node. Any parts of other types are each stored in separate files and given "file" class nodes that are linked to the "msg" node. . In a multipart/alternative message or part, we look for a text/plain subpart and ignore the other parts. . A message/rfc822 is treated similar tomultipart/mixed (except for special handling of the first text part) if unpack_rfc822 is set in the mailgw config section. Summary ------- The "summary" property on message nodes is taken from the first non-quoting section in the message body. The message body is divided into sections by blank lines. Sections where the second and all subsequent lines begin with a ">" or "|" character are considered "quoting sections". The first line of the first non-quoting section becomes the summary of the message. Addresses --------- All of the addresses in the To: and Cc: headers of the incoming message are looked up among the user nodes, and the corresponding users are placed in the "recipients" property on the new "msg" node. The address in the From: header similarly determines the "author" property of the new "msg" node. The default handling for addresses that don't have corresponding users is to create new users with no passwords and a username equal to the address. (The web interface does not permit logins for users with no passwords.) If we prefer to reject mail from outside sources, we can simply register an auditor on the "user" class that prevents the creation of user nodes with no passwords. Actions ------- The subject line of the incoming message is examined to determine whether the message is an attempt to create a new item or to discuss an existing item. A designator enclosed in square brackets is sought as the first thing on the subject line (after skipping any "Fwd:" or "Re:" prefixes). If an item designator (class name and id number) is found there, the newly created "msg" node is added to the "messages" property for that item, and any new "file" nodes are added to the "files" property for the item. If just an item class name is found there, we attempt to create a new item of that class with its "messages" property initialized to contain the new "msg" node and its "files" property initialized to contain any new "file" nodes. Triggers -------- Both cases may trigger detectors (in the first case we are calling the set() method to add the message to the item's spool; in the second case we are calling the create() method to create a new node). If an auditor raises an exception, the original message is bounced back to the sender with the explanatory message given in the exception. -------------- next part -------------- Return-Path: X-Original-To: report at bugs.python.org Delivered-To: roundup+tracker at psf.upfronthosting.co.za Received: from mail.python.org (mail.python.org [82.94.164.166]) by psf.upfronthosting.co.za (Postfix) with ESMTPS id 0929456919 for ; Thu, 13 Jun 2013 03:26:08 +0200 (CEST) Received: from albatross.python.org (localhost [127.0.0.1]) by mail.python.org (Postfix) with ESMTP id 3bW6jC5QQ0z7Ljp for ; Thu, 13 Jun 2013 03:26:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1371086767; bh=wMw826ZtGBEUB/Qfpd9S7/ylomvtA8Eh3djOC3m+gFY=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To: Subject:Message-Id:Date; b=rPercnBT6gUe8pECEZld/NBXfeBalPL1bRrS+EBfvck1hmS7mU8DtlD8vRbva9X4D I4hOJdTGbdrQkUQUqyWMdl1kKhjnoe0tmLJ5BX9v78OHaGUjOPu+/dIzbmCpwpp9nG 7xzvmo3Ue0063PzbXSq4u6AEuM17iZKXk9FuCHVA= Received: from localhost (HELO mail.python.org) (127.0.0.1) by albatross.python.org with SMTP; 13 Jun 2013 03:26:07 +0200 Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org [140.211.10.72]) by mail.python.org (Postfix) with ESMTP for ; Thu, 13 Jun 2013 03:26:07 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: tracker-discuss at python.org To: report at bugs.python.org Subject: [issue281857369] Message-Id: <3bW6jC5QQ0z7Ljp at mail.python.org> Date: Thu, 13 Jun 2013 03:26:07 +0200 (CEST) TmV3IGNoYW5nZXNldCAwMTdjNDMxZDE3OTggYnkgQnJldHQgQ2Fubm9uIGluIGJyYW5jaCAnZGVm YXVsdCc6ClBhcnRpYWxseSByZXZlcnQgY2hhbmdlc2V0ICMyODE4NTczNjlhNzggdG8gbWFrZSBz dXJlIHRocmVhZHMgYXJlCmh0dHA6Ly9oZy5weXRob24ub3JnL2NweXRob24vcmV2LzAxN2M0MzFk MTc5OAo= From metatracker at psf.upfronthosting.co.za Fri Jun 28 09:17:37 2013 From: metatracker at psf.upfronthosting.co.za (Ronald Oussoren) Date: Fri, 28 Jun 2013 07:17:37 +0000 Subject: [Tracker-discuss] [issue518] Plaintext connections when logging in Message-ID: <1372403857.35.0.242184511597.issue518@psf.upfronthosting.co.za> New submission from Ronald Oussoren: All communication with bugs.python.org is over plain HTTP, not HTTPS. This includes user authentication. This means it is unsafe to log in from an untrusted network when your using a username/password to log in. I don't know enough of OpenID to know if that's safer to use. A possible solution to this problem is to HTTPS-enable the bug reporter (as was done for PyPI) ---------- messages: 2735 nosy: ronaldoussoren priority: wish status: unread title: Plaintext connections when logging in _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Jun 28 17:13:13 2013 From: metatracker at psf.upfronthosting.co.za (R David Murray) Date: Fri, 28 Jun 2013 15:13:13 +0000 Subject: [Tracker-discuss] [issue518] Plaintext connections when logging in In-Reply-To: <1372403857.35.0.242184511597.issue518@psf.upfronthosting.co.za> Message-ID: <1372432393.04.0.543011343374.issue518@psf.upfronthosting.co.za> R David Murray added the comment: As Martin (I think) has said, just how damaging would compromising this password be? Tracker changes are all reversible. On the other hand I'm in favor of using https in general. This was discussed on the infrastructure list, and the issue is that bugs is hosted on different infrastructure. bugs is probably the last service that will be addressed. If this concerns you enough you could check back in the infrastructure mailing list archives for that discussion, and figure out whether there is a next step we could take in the meantime (I think putting a copy of the *.python.org cert or getting a bugs.python.org cert was discussed, but I don't remember for sure). I'm willing to help with the server config part of it, but I'm not worried enough about it to drive the process myself :) ---------- nosy: +r.david.murray status: unread -> chatting _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Jun 28 19:44:12 2013 From: metatracker at psf.upfronthosting.co.za (Ronald Oussoren) Date: Fri, 28 Jun 2013 17:44:12 +0000 Subject: [Tracker-discuss] [issue518] Plaintext connections when logging in In-Reply-To: <1372403857.35.0.242184511597.issue518@psf.upfronthosting.co.za> Message-ID: <1372441452.51.0.843698290341.issue518@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There are appearently a lot of people that reuse passwords across sites, or use recognizable patterns in passwords for sites. Anyway, non-https logins worry me enough that I try to avoid using them when I'm on a network where there is a clear chance of interception. I've attached an OpenID to my account, so should be safe enough during EuroPython ;-) _______________________________________________________ PSF Meta Tracker _______________________________________________________ From metatracker at psf.upfronthosting.co.za Fri Jun 28 20:43:22 2013 From: metatracker at psf.upfronthosting.co.za (R David Murray) Date: Fri, 28 Jun 2013 18:43:22 +0000 Subject: [Tracker-discuss] [issue518] Plaintext connections when logging in In-Reply-To: <1372403857.35.0.242184511597.issue518@psf.upfronthosting.co.za> Message-ID: <1372445002.61.0.716152136804.issue518@psf.upfronthosting.co.za> R David Murray added the comment: Well, yes, I know that is common. Unfortunately, https doesn't solve that lack of security knowledge, since if one account gets cracked because of insecure servers, the rest of their accounts are also compromised. _______________________________________________________ PSF Meta Tracker _______________________________________________________