Re: [Python-Dev] Mercurial migration: help needed
On Sat, Aug 22, 2009 at 01:17, Martin Geisler wrote: > In the general case, you can specify an extension to be enabled by > filename: > > [extensions] > foo = ~/src/foo > > So if I can enable an extension like that on your system, I might be > evil and commit a bad extension *and* enable it at the same time. > > You might argue that one should then limit which extensions one can > enable in a versioned file, but it seems hard to come up with a good > mechanism for this. The current "mechanism" is the users own ~/.hgrc > file which can be seen as a whitelist of extensions he trust. Thanks for explaining that bit, Martin. Everyone: Martin is also a hg crew member. It sounds to me like somehow requiring extensions to be enabled (without actually enabling them) would help mitigate the issues somehow, although it's still a distributed system and so clients cannot be trusted (e.g. I might put a win32text stub in there somewhere that does nothing). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Mark Hammond writes: > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: > Possibly - although I would expect the existing section names be reused > when applied to a versioned file, I'd be more than happy for the hg guys > to declare new names are appropriate for this. If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules. > > > This way you aren't *enabling* extensions in this versioned file, > > > > True, but how many people will just download the extension and enable > > it? > > In the ideal world, exactly as many people who would read the Python > developer guide, then download and install the extension based purely on > that. IOW, it is Python itself setting the policy, so people need to > make their own decisions based on that, regardless of whether the tool > enforces it or not. You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by "social engineering," and why I worry about policy pushback from Mercurial HQ. Maybe that's more paranoid than they are But it can't hurt your cause to be ready for that kind of worry. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Dirkjan Ochtman writes: > [Clients] cannot be trusted (e.g. I might put a win32text stub in > there somewhere that does nothing). Heck, just edit the .hgrules file, and do a Houdini on any and all handcuffs. Don't trust software, trust people -- but help them avoid thoughtless mistakes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
> From my POV, this would be required in some form or another before such > a scheme could actually work. Without it we end up with an improved > win32text (good!) I still think this would be actually bad. Instead, a new extension should be written, with a name that does not have "win32" as a substring, and that has no provision for guessing line breaks by inspecting files. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’
> What is the procedure for finding out why an issue hasn't progressed? It's fairly simple: just read through the issue, and it should be obvious. In the specific case, no committer has ever commented on the issue, so chances are high that no committer has ever *seen* the issue. > I don't want to fill the bug database with such noise. And likely, posting to the issue won't be a way to find out, since no committer would see your comment. > In the case of http://bugs.python.org/issue1170> (“shlex have > problems with parsing unicode”), the problem is apparently addressed by > a patch, assigned to that issue since 2007-12-22. Apparently, or really? Did you review the patch? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
"Stephen J. Turnbull" writes: > Mark Hammond writes: > > [extensions] > required_for_commit = win32text,some_other_ext > > That might require a change to hg's ini file semantics if currently it > refuses to parse [extension] sections in versioned hgrcs. It doesn' refuse anything like that. When Mercurial starts, it reads these configuration files: http://www.selenic.com/mercurial/hgrc.5.html#files Notice that they are all outside the clone's working directory, the closes one is the /.hg/hgrc file. As I wrote somewhere else in this thread, you can add %include ../.repo-settings in your /.hg/hgrc file, and this will result in /.repo-settings being loaded (and this file *is* in the working copy and can thus be put under revision control). -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpmaXyOsnq7C.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
"Stephen J. Turnbull" writes: > Mark Hammond writes: > > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: > > > Possibly - although I would expect the existing section names be reused > > when applied to a versioned file, I'd be more than happy for the hg guys > > to declare new names are appropriate for this. > > If there's already an [Encode] section, that's different. (I don't > details, I'm not that big a Mercurial fan.) But you'd still need a > way to differentiate win32text rules from other encoding rules. There is a [decode] and an [encode] section: http://www.selenic.com/mercurial/hgrc.5.html#decode-encode The win32text extension works by defining new filters which can then be used like this: [encode] ** = cleverencode: [decode] ** = cleverdecode: (they are "clever" because they skip binary files) >>> True, but how many people will just download the extension and >>> enable it? >> >> In the ideal world, exactly as many people who would read the Python >> developer guide, then download and install the extension based purely >> on that. IOW, it is Python itself setting the policy, so people need >> to make their own decisions based on that, regardless of whether the >> tool enforces it or not. > > You're missing the point. I'm not talking about whether it will work > for Python, I'm talking about the worry that somebody will post a way > cool Python branch and require a private extension, which everybody > will just automatically install and enable, which extension then > proceeds to phone home to Spammer Haven, Inc. with the contents of > your email contact list. That's what I mean by "social engineering," > and why I worry about policy pushback from Mercurial HQ. > > Maybe that's more paranoid than they are But it can't hurt your > cause to be ready for that kind of worry. Oh, we try to be very paranoid in Mercurial :-) That's why you don't see any support for copying hgrc files when you clone and why hg wont trust hgrc files not owned by you: it should be safe to do cd ~collegue/src/python hg tip -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgpAl8dMJYc9u.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
2009/8/22 Martin Geisler : > Oh, we try to be very paranoid in Mercurial :-) That's why you don't see > any support for copying hgrc files when you clone and why hg wont trust > hgrc files not owned by you: it should be safe to do > > cd ~collegue/src/python > hg tip So, is the implication therefore that there would be resistance to having some way of making a setting which *is* copied on clone, which says that you can't commit in this repository unless you have the following extensions enabled? Or is the fact that it's only saying "you must have an extension called win32text enabled" and not actually enabling code directly, sufficiently secure to make it acceptable? Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Paul Moore writes: > 2009/8/22 Martin Geisler : >> Oh, we try to be very paranoid in Mercurial :-) That's why you don't >> see any support for copying hgrc files when you clone and why hg wont >> trust hgrc files not owned by you: it should be safe to do >> >> cd ~collegue/src/python >> hg tip > > So, is the implication therefore that there would be resistance to > having some way of making a setting which *is* copied on clone, which > says that you can't commit in this repository unless you have the > following extensions enabled? It sounds somewhat invasive to forbid commits. Moreover, repository owners should remember that clients can do whatever they want, so this can only be a hint, never a requirement. I don't think this has been mentioned: When you clone you move history (changesets) only and I'm pretty sure you cannot even read the configuration settings over the "wire protocol". So cloning from a HTTP URL wont copy a setting found in the /.hg/hgrc file. This implies that the settings should live in a version controlled file. I think that is sensible under all circumstances. So if the win32text extension (horrible name, I agree... it should have been made more general and called eolconvert or something like that) would just read a configuration file from the repository, then all you should ask people is to enable win32text. > Or is the fact that it's only saying "you must have an extension > called win32text enabled" and not actually enabling code directly, > sufficiently secure to make it acceptable? It is definitely secure enough to be included. There should be a way to turn off those hints, though: I might want to clone the Python repository and play around with it without enabling win32text. -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. pgp94ixQNXvhg.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
Stephen J. Turnbull wrote: > Dirkjan Ochtman writes: > > > [Clients] cannot be trusted (e.g. I might put a win32text stub in > > there somewhere that does nothing). > > Heck, just edit the .hgrules file, and do a Houdini on any and all > handcuffs. > > Don't trust software, trust people -- but help them avoid thoughtless > mistakes. Yes, on the client side we're not trying to prevent someone doing the wrong thing deliberately - just nudging them towards doing the right thing so they won't run afoul of the server side checks that will actually *enforce* the line ending rules for the main repository. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Setting up a buildbot
I've just had a look on python.org, but couldn't immediately see a pointer to instructions on what the process is to set up a buildbot. There's a not on setting things up for pybots, but nothing on the core buildbot setup. The reason I'm asking is that I'm thinking of seeing if I could set up a Windows buildbot of some sort, to offer extra coverage. It's early days, yet, but I wonder if someone could answer a few questions for me: - Is there any documentation on how to set up a buildbot? If so, can someone give me a pointer? - What configurations would be most useful? (I've got a 64-bit PC, so I can theoretically set up 32 or 64 bit VMs with VMWare, and with my shiny new MSDN subscription, I can set up whatever OS is most useful). - Is it possible to set up the pull/build/test side of the process separately, before linking it into the full buildbot farm? That would let me try things out on my own, and iron out any configuration glitches before dumping it on the world. Thanks for any pointers. It's early days yet, so it may be a while before I have anything properly set up, but I'd like to see what I can do. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a buildbot
-On [20090822 21:30], Paul Moore (p.f.mo...@gmail.com) wrote: >I've just had a look on python.org, but couldn't immediately see a >pointer to instructions on what the process is to set up a buildbot. http://wiki.python.org/moin/BuildBot comes to mind. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Success is satisfaction with yourself... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a buildbot
2009/8/22 Jeroen Ruigrok van der Werven : > -On [20090822 21:30], Paul Moore (p.f.mo...@gmail.com) wrote: >>I've just had a look on python.org, but couldn't immediately see a >>pointer to instructions on what the process is to set up a buildbot. > > http://wiki.python.org/moin/BuildBot comes to mind. Ah, thanks. I'll take a look. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On Fri, Aug 21, 2009 at 6:58 PM, Mark Hammond wrote: > [encode] > *.dsp=none: > **=cleverencode: > > The end result should be that anything with 'none:' forms what you call an > ignore list. > > Would that not meet your requirements? It would, so I guess I'll hold off on digging into the hook code ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote: Mark Hammond writes: > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: > Possibly - although I would expect the existing section names be reused > when applied to a versioned file, I'd be more than happy for the hg guys > to declare new names are appropriate for this. If there's already an [Encode] section, that's different. (I don't details, I'm not that big a Mercurial fan.) But you'd still need a way to differentiate win32text rules from other encoding rules. As mentioned in my previous post, I'm trying to avoid bike-shedding what the hg guys are better placed to decree. How they choose to spell these options is something for hg to decide, and I doubt my opinion matters enough to bother sharing, let alone advocating. > >> This way you aren't *enabling* extensions in this versioned file, > > > > True, but how many people will just download the extension and enable > > it? > > In the ideal world, exactly as many people who would read the Python > developer guide, then download and install the extension based purely on > that. IOW, it is Python itself setting the policy, so people need to > make their own decisions based on that, regardless of whether the tool > enforces it or not. You're missing the point. I'm not talking about whether it will work for Python, I'm talking about the worry that somebody will post a way cool Python branch and require a private extension, which everybody will just automatically install and enable, which extension then proceeds to phone home to Spammer Haven, Inc. with the contents of your email contact list. That's what I mean by "social engineering," and why I worry about policy pushback from Mercurial HQ. No, you are missing the point - social engineering doesn't require tool support - tools simply make certain things easier. Maybe that's more paranoid than they are But it can't hurt your cause to be ready for that kind of worry. If this becomes seen as 'my' cause, I suspect it will run out of steam very quickly. I truly hope python-dev, as a community, takes some ownership of this issue or I predict the effort will fizzle out without a workable solution. There seem to be a number of people who agree the status-quo isn't acceptable, so I'm not sure what would happen in that case... Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: help needed
On 22/08/2009 7:09 PM, "Martin v. Löwis" wrote: From my POV, this would be required in some form or another before such a scheme could actually work. Without it we end up with an improved win32text (good!) I still think this would be actually bad. Instead, a new extension should be written, with a name that does not have "win32" as a substring, and that has no provision for guessing line breaks by inspecting files. To be clear, you are suggesting: * Having hg enforce an extension as required is good. * Python adopting win32text as that extension would be bad - instead another extension with different semantics (ie, no guessing based on file content) should be used, and enforced, instead. Or have I misunderstood? Assuming I am correct, I am inclined to agree - win32text may be "good enough" in the short term, but it is far from ideal. Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 1170: Unicode for ‘shlex ’
Benjamin Peterson writes: > I will leave a few initial comments. Thank you. "Martin v. Löwis" writes: > > In the case of http://bugs.python.org/issue1170> (“shlex have > > problems with parsing unicode”), the problem is apparently addressed > > by a patch, assigned to that issue since 2007-12-22. > > Apparently, or really? Did you review the patch? No. The bug report showed that others had already tried it and said it worked; and also, I don't consider myself qualified to review that particular patch. > > What is the procedure for finding out why an issue hasn't progressed? > > It's fairly simple: just read through the issue, and it should be > obvious. In the specific case, no committer has ever commented on the > issue, so chances are high that no committer has ever *seen* the > issue. Okay, so not obvious to someone (like me) who doesn't immediately know who is or is not a committer. Thanks for the clarification. > > I don't want to fill the bug database with such noise. > > And likely, posting to the issue won't be a way to find out, since no > committer would see your comment. I'll take that as confirmation that asking in this forum is the right procedure. -- \ “We spend the first twelve months of our children's lives | `\ teaching them to walk and talk and the next twelve years | _o__) telling them to sit down and shut up.” —Phyllis Diller | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
