[Tracker-discuss] [issue605] Python tracker needs two classes of "easy" issues -- requiring C or not
R David Murray writes: > (At least, I think one can retire tags, I haven't actually > checked). I've done it on the XEmacs tracker, so it used to work fine, but that was a while ago. Steve ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss Code of Conduct: https://www.python.org/psf/codeofconduct/
[Tracker-discuss] [issue564] Password reset sends new password to wrong email
Ian Kelly writes: > Instead of or in addition to the primary email address on the > account, it seems to me that these emails should at minimum be sent > to the email address that was used to initiate the password reset. I assume you mean that the email used to reset is in fact registered as a secondary address on that user. If not, it's clearly a major security hole. ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss
Re: [Tracker-discuss] External bug report monitoring
anatoly techtonik writes: > How can they choose bugs that are only related to Debian? They can't. But they certainly do get a lot of them. I made an effort to follow the Debian bugs for XEmacs for almost a year, but it's sort of like checking your spam folder for false positives. There's some gold there, but not enough to make it worthwhile. Many of their bugs have to do with packaging, or worse with patches that they apply to fit things into their standard package organization, and occasionally to fix bugs -- the latter often backports of fixes already in upstream trunk. > Also this is the only way to get feedback from Python people who > are not registered at Debian tracker. This will benefit both Debian > and Python. For use, in the end it did pretty much nothing for XEmacs or Debian; that's why I stopped. *They* were pretty good about forwarding relevant bugs upstream, but very little came from my efforts -- and not because I wasn't diligent for those months, but because there just wasn't that much of any relevance left after their forwards. The situation here would be worse, because AIUI you propose to collect those bugs automaticly: somebody would have to close all the irrelevant bugs. ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] Pseudo protection of b.p.o from MITM
Anatoly, don't you know that cross-posting is a bad idea?[1] If you disagree with the management of bugs.python.org, tracker-discuss is the right place to post. anatoly techtonik writes: > The b.p.o uses CAcert certificate that was never valid on Windows Of course it was valid, it was simply not trusted by default. Given Microsoft's historical aversion to "free" anything, that's a completely null signal. > and now removed from Ubuntu and Debian, and yet, some people push > the idea that it is OK to continue using such certificate for > b.p.o. As pointed out (and never denied) in the thread[2] explaining why Debian removed CAcert, Debian's "include only 'trustworthy' root certificates" policy is broken, both in theory and in practice. With regard to CAcert, there are no known exploits -- which is not true of several of the other authorities in Debian's bundle (which is mostly taken from Mozilla). Perhaps it's worth moving to a different free root authority, or maybe even (gasp!) paying for a well-known commercial certificate, but you need to find one that satisfies the technical requirement posted by Martin -- namely, that certs for a particular host should *not* allow escalation of privilege to all hosts in the python.org domain. (Note that if we use a commercial service this probably becomes rather expensive.) There may be other requirements I don't know about. Personally, since I think that the X.509 architecture is broken at the top in practice (why is Verisign trustworthy? how about the Chinese National Network Information Center? or the Japanese Ministry of Education (my employer)? yet most systems -- including Windows -- default to trusting any certificate issued by any of them), having a root cert that seems trustworthy to me, yet isn't trusted by default, allowing me to *choose* to assign an appropriate amount of trust to bugs.python.org, seems to be the most secure option. I don't know if it's any better than a self-signed cert, of course. > I disapprove the decision of these people What else is new? > and hope that somebody from python community can change their > convoluted understanding of security. Security *is* convoluted, and your own understanding of it seems to be limited since you misuse technical terms like "valid" (there's a difference between "cannot be validated" and "not valid"). Footnotes: [1] Among other things, it makes it likely that the ban on your participation will be extended. ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] [issue472] b.p.o logo link back to python.org
Ezio Melotti writes: > > Ezio Melotti added the comment: > > Here's a log that includes "bug tracker". Very nice, but I'd make "bug tracker" a little bit larger. Personal taste, I'm not a graphic artist or anything. ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] Fwd: [PSRT] Cross-Site Scripting(XSS) vulnerability found on your website
Benjamin Peterson writes: > Not sure if this is interesting. > 2. As soon as we submit the crafted URL, we get an alert box saying XSS. >URL: > > > http://bugs.python.org/issue?%40columns=status&message_count=";>
[Tracker-discuss] Disallow: /msg* for http://bugs.python.org/robots.txt
anatoly techtonik writes: > cc: tracker-discuss for comments, please reply to infra > *Hi,I'd like to patch http://bugs.python.org/robots.txt with: > > Disallow: /msg* > > This should prevent indexing of individual messages, which are > included on bug pages anyway. It might work that way, but it shouldn't. From the Robot Exclusion Standard: Disallow The value of this field specifies a partial URL that is not to be visited. This can be a full path, or a partial path; any URL that starts with this value will not be retrieved. For example, Disallow: /help disallows both /help.html and /help/index.html[.] So just Disallow: /msg is presumably what you want. ___ Tracker-discuss mailing list Tracker-discuss@python.org https://mail.python.org/mailman/listinfo/tracker-discuss
Re: [Tracker-discuss] PyCon Sprints for Roundup
anatoly techtonik writes: > And FWIW, I already have commit access for Roundup. Then I don't understand the tone of your post to tracker-discuss at all. You have the itch, you should scratch it, and you have the access to do that (the Python tracker code is public and I assume appropriately licensed). If you're trying but need help, why not say "I need help"? If you're not trying to do that, why don't those principles apply to you? The Python developers are all quite aware of the benefits of contributing back upstream. Therefore *I* infer that contributing back to Roundup was not as simple as requesting and exercising commit access. I wonder why you don't make the same inference, or perhaps communicate that awareness in your posts if you have made it? > If you don't want b.p.o to be the place where people communicate > and coordinate in a human way, then I bet you'd more comfortable > using Excel for your own tasks, so thanks for caring about > independence of Roundup from Python hackers. b.p.o is already a place where humans communicate in human ways. What else could it be? I suppose there could be more efficient or more pleasant ways of communicating, or more similar to the way people communicate in daily life, but the suggestions you've made in the past (e.g., voting on bugs) have never struck me as ways to make Python *development* more pleasant or more efficient (both personal opinions, but that is sufficient reason to refrain from supporting a suggestion). I can see where some people might *enjoy* having those features; but (to repeat), I don't see a benefit to the development process to outweigh the cost of providing, maintaining, and using them. It would seem from the reaction of the tracker maintainers (they rarely, if ever, take up your suggestions) that you have not succeeded in convincing them of the benefits of those suggestions, either. > Am I angry at you accusing me of something that is not true, I'm not accusing you of something that is not true. I am telling you what your words mean to me. Note the first six words you quoted: > On Wed, Mar 20, 2013 at 2:41 AM, Stephen J. Turnbull > wrote: > > As far as I can tell, you're suggesting that Python should take > > over and/or try to dictate to another established project. As a participant in Python mailing lists, my duty is to read your *words*, not your mind. If it were just me, you could (and perhaps should) ignore me. But AFAICT I'm giving voice to opinions held by many on Python lists. If they're based on misunderstanding, it's your place to correct that misunderstanding, or, better, avoid causing it in the first place. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
Re: [Tracker-discuss] PyCon Sprints for Roundup
anatoly techtonik writes: > b.p.o still uses patched version of Roundup while with a full upstream > commit access it should use standard version. As far as I can tell, you're suggesting that Python should take over and/or try to dictate to another established project. I don't think that's a good idea. If you really think these things are that important, go work with upstream, get commit access there yourself. > We need to recruit more people then. Who's this "we"? I'm perfectly happy with b.p.o, I don't need it to turn into facebook.python.org. But feel free to go recruiting. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] Abuse Message
Izak Burger writes: > I've cleared out the contents of the file so that this will no longer > happen. The original file is in the roundup user's home directory, > file 291, in case anyone wants to see what was done, but it appears to > be a javascript attack. I mostly just lurk on this list and don't have shell access to the Python tracker. However I do run a roundup tracker, and am a little concerned about this. Does it seem to be roundup-specific? Could you mail me a copy of the exploit file? Steve ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
Re: [Tracker-discuss] [Python-Dev] Posting frequent spurious changes in bugtracker
Now that Jesus has provided a heads-up, detailed discussion belongs on the metatracker IMO. Warning: Reply-To set to tracker-discuss@python.org. metatracker workers: Created issue500. More info: see this thread: http://mail.python.org/pipermail/python-dev/2013-January/123437.html Brett Cannon writes: > > Or am I doing something fundamentally wrong?. I reflesh 99% of the > > time, but could forget sometimes, and some other times I need a > > "shift+reload" to bypass browser cache. > > > Well, I would argue you are doing something fundamentally wrong by > submitting anything without refreshing first. It is a form so technically > nothing is being done incorrectly in changing values based on what you > submit, whether you view them stale or not. That's beside the point, Brett. First, his intent is to refresh, so he's doing his best - he merely admits he's human, and would like help from the machine. But the nub of his report is the fact that nothing he *can* do seems to do the whole job of refreshing. Nor is he complaining about the form processing at the HTML/HTTP level. The limits of the HTTP transport don't justify the defects of the database backend, although they are likely to cause inconvenience to users (ie, the easy patch is to block the whole update, rather than update only the fields the user has explicitly changed). I need to update XEmacs's tracker anyway, I'll investigate whether upstream has a fix for this, and if not, see if I can come up with a patch for this while I'm updating. Technically it shouldn't be hard to implement Jesus's suggestion, and at least reject potential spurious updates (the tracker db has a timestamp on every change). metatracker workers: no ETA on this, feel free to ping me for updates or prod me to get to work. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] [issue373] Add 'module' field to tracker
R David Murray writes: > Having a way for non-commiters to indicate to everyone In XEmacs's Roundup we allow any user to assign themselves an "assignable" Role (which is misnamed "Developer"). All this does is add them to the list that pops up for "Assigned-To" (there is also an assign-to-me option there which allows anybody to assign an issue to themselves, whether they have the Developer Role or not). This was trivial. A couple lines to create the Role in schema.py, and a couple lines in the issue template to filter in Reviewers and Developers in the Assign-To menu. > (but especially triagers) that they are interested in helping with > a given module would be a nice feature. Limiting a user's offer to a given module would be more effort to implement, but shouldn't be too hard. Probably the code would be very similar to the auto-nosy that some maintainers have for modules they maintain. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] [issue312] Add a 'go to the last message' link
R David Murray writes: > I disagree that the actions are "mostly useless", Did somebody actually write that? I didn't. > or even that the 'nosy' change information is noise. While I don't > refer to the action list often, I do refer to it regularly to > answer some question about actions taken on the issue. And I'd > guess that about half the time I do I'm checking to see when > someone got added as nosy and whether they did it themselves or if > someone else added them (and if so, I sometimes care about who did > the add). I was incautious in my phrasing. By "filter out" I meant to imply "into a list at the bottom". If you are checking explicitly, ISTM it's more convenient to have a compact list at the bottom of the page to check, rather than looking for the action interleaved with all the messages. But when interlined, most of the time "nosy += me" really is just noise, and when you get 20 in a row, it's quite annoying. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] [issue378] Merge OpenID login feature upstream
Martin v. Löwis writes: > > Martin v. Löwis added the comment: > > openid2rp is a separate package. It doesn't need to be incorporated into > roundup. I don't see what the problem is, anyway. The AFL is a permissive, noncopyleft license, and sublicensable. That specifically means that roundup can apply any license it likes to the whole, subject to a one time change in COPYING. Something similar was already done for PageTemplates (actually, that's more than is required for the AFL). Furthermore, if openid2rp is distributed without change, and not copied into roundup, absolutely no license obligations are created at all. See http://www.rosenlaw.com/OSL3.0-explained.pdf, p. 7. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] Backups for PSF
Izak Burger writes: > It is my pleasure to announce that the last bit of dependency on the old > host is now gone. W00t! > I made use of the free space Hetzner provides for > backups to make a daily backup of the important parts of the psf virtual > host. Very cool! (Sorry, no comment on appropriateness of backup content; looks good to me, but I'm no expert, especially not on the PSF host.) ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
[Tracker-discuss] Fwd: Abuse Message [AbuseID:025FD3:14]: AbuseAOL: Email Feedback Report for IP 88.198.142.26
Izak Burger writes: > Someone at AOL thinks a password reset message is spam. Any ideas on how > this happened? This is very common with AOL. First (most likely in this case) AOL puts the SPAM button right next to the DELETE button, and AFAIK there's no feedback to the user making it inconvenient to miss. From the user's point of view, they both just make the message disappear. I suppose the confirmation message is a little bit different, but I don't read those messages from my MUAs. I don't suppose anyone reads them at AOL, either, unless they didn't want to delete the message. Second (probably not applicable to someone with a Python tracker account, though), that's the user base that AOL targets: ignorant and loving it. Many AOL users apparently think of any unwanted mail as spam, even if they requested it themselves and later changed their minds. Third, it could be a joe job: somebody who doesn't like the user signed them up for a bunch of mailing lists. I've also heard rumors of bots doing this to grab email addresses out of the list traffic, but that seems pretty perverse, even for a bot, when it's so easy to create a throwaway account that won't upset anybody somewhere and sign that up. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
Re: [Tracker-discuss] [pydotorg-www] offline 10-10-18
anatoly techtonik writes: > Don't you find it strange that I am the only one who reported the > outage and I am not really active in Python development (this probably > the first time I opened tracker page in last 10 days)? Not strange at all. Random things like that do happen. Also, I don't know about you, but my network has been quite unreliable across regions, oh, once or twice a month. Sometimes it fails on the U.S., sometimes it fails on Europe, sometimes on south or east Asia (and all too often the whole thing goes down locally; thank heaven the public Internet is more reliable than my university's intranet!) If others are experiencing the same, they may just wait 12-24 hours before reporting a problem. It's good that you report, but it's not that surprising that you were the first. And you may or may not be the only reporter; I would guess that private reports to me (or an admin-specific alias) outnumber public reports to lists by 2:1 for the trackers I administer. ___ Tracker-discuss mailing list Tracker-discuss@python.org http://mail.python.org/mailman/listinfo/tracker-discuss
