Re: [Python-Dev] Support for Encrypted Zip as python scripts
-On [20090823 22:10], Guido van Rossum (gu...@python.org) wrote: >Also, I suppose there could be (US) export problems with the code, so it >would have to be optional (and we might not be able to build it into >binaries we distribute from python.org). For all I know the website and repository are both located @ the XS4All colocation, so how does US export problems apply? It would apply if the box would've been hosted in the USA, but they're not for all I know. It's one of the reasons FreeBSD had their ebones repository located in Zuid Afrika back in the day. Nowadays they can just include all the relevant bits in the repository. So I wonder how applicable the entire US export restriction still is nowadays. In short: I don't think we have much to worry about. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Wisdom is the difference between knowledge and experience... ___ 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] Support for Encrypted Zip as python scripts
On Mon, Aug 24, 2009 at 1:54 AM, Jeroen Ruigrok van der Werven wrote: > -On [20090823 22:10], Guido van Rossum (gu...@python.org) wrote: >>Also, I suppose there could be (US) export problems with the code, so it >>would have to be optional (and we might not be able to build it into >>binaries we distribute from python.org). > > For all I know the website and repository are both located @ the XS4All > colocation, so how does US export problems apply? It would apply if the box > would've been hosted in the USA, but they're not for all I know. > > It's one of the reasons FreeBSD had their ebones repository located in Zuid > Afrika back in the day. Nowadays they can just include all the relevant bits > in the repository. So I wonder how applicable the entire US export > restriction still is nowadays. > > In short: I don't think we have much to worry about. Are you a lawyer? Do you know the legal history of Python distributions and the US export laws? It's not so easy -- for one, the PSF (a US foundation) owns the copyright. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] runpy.py
Guido van Rossum wrote: Anyway it looks like if someone wants to try this, only the code in runpy.py needs to be touched. Where is runpy.py to be found? I'm trying to find whatever implements python -m and the other python command line options... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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] runpy.py
2009/8/24 Chris Withers : > Guido van Rossum wrote: >> >> Anyway it looks like if someone wants to try this, only the code in >> runpy.py needs to be touched. > > Where is runpy.py to be found? $ find . -name "runpy.py" ./Lib/runpy.py -- Regards, Benjamin ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Fri, Aug 21, 2009 at 4:41 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> On Thu, Aug 20, 2009 at 10:15 PM, Case Vanhorsen wrote:
>>> I was surprised that IP('172.16.1.1') returned
>>> IPv4Address('172.16.1.1/32') instead of IPv4Address('172.16.1.1'). I
>>> know I can change the behavior by using host=True, but then
>>> IP('172.16.1.1/24', host=True) will raise an error. It makes more
>>> sense, at least to me, that if I input just an IP address, I get an IP
>>> address back. I would prefer that IP('172.16.1.1/32') return an
>>> IPv4Network and IP('172.16.1.1') return an IPv4Address.
>>
>> I think you mean that it returns an IPv4Network object (not
>> IPv4Address). My suggestion there is that if you know you're dealing
>> with an address, use one of the IPvXAddress classes (or pass host=True
>> to the IP function). IP is just a helper function and defaulting to a
>> network with a /32 prefix seems relatively common.
>>
>> Knowing that my experience may not always be the most common, I can
>> change this behavior if it's indeed confusing, but in my conversations
>> with others and in checking out the current state of ip address
>> libraries, this seems to be a perfectly acceptable default.
>
> The IP() helper function actually bothers me a bit - it's a function
> where the return *type* depends on the parameter *value*. While
> switching between IPv4 and IPv6 based on value is probably a necessary
> behaviour, perhaps it would be possible to get rid of the "host=True"
> ugliness and instead have two separate helper functions:
>
> IP() - returns either IPv4Address or IPv6Address
> IPNetwork() - returns either IPv4Network or IPv6Network
IPAddress() and IPNetwork seem a little less confusing. I'll get rid
of IP() since it seems to be the source of a fair bit of confusion.
I've added this to the pep3144 change. need to change the pep to
reflect this now.
> Both would still accept a version argument, allowing programmatic
> control of which version to accept. If an unknown version is passed then
> some kind of warning or error should be emitted rather than the current
> silent fallback to attempting to guess the version based on the value.
>
> I would suggest removing the corresponding IPv4 and IPv6 helper
> functions altogether.
done.
> My rationale for the above is that hosts and networks are *not* the same
> thing. For any given operation, the programmer should know whether they
> want a host or a network and ask for whichever one they want. The
> IPv4/IPv6 distinction, on the other hand, is something that a lot of
> operations are going to be neutral about, so it makes sense to deal with
> the difference implicitly.
makes sense to me.
> Other general comments:
>
> - the module appears to have quite a few isinstance() checks against
> non-abstract base classes. Either these instance checks should all be
> removed (relying on pure duck-typing instead) or else the relevant
> classes should be turned into ABCs. (Note: this comment doesn't apply to
> the type dispatch in the constructor methods)
I'll look through this.
> - the reference implementation has aliased "CamelCase" names with the
> heading "backwards compatibility". This is inappropriate for a standard
> library submission (although I can see how it would be useful if you
> were already using a different IP address library).
this is for legacy reasons (how it's used at work). it's fully
expected that those will disappear if/when this is accepted.
> - isinstance() accepts a tuple of types, so isinstance(address, (int,
> long)) is a shorter way of writing "isinstance(address, int) or
> isinstance(address, long)". The former also has the virtue of executing
> faster. However, an even better approach would be to use
> operator.index() in order to accept all integral types rather than just
> the builtin ones.
I can easily make the change to checking tuples. I'd have to look
further at the operator.index() to see what's required.
> 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
Re: [Python-Dev] Support for Encrypted Zip as python scripts
I like the idea, but... Here is a quick list of things to think about and if some of this has already been mentioned, sorry. Speed: Encryption speed has been mentioned. For short scripts this may not be a problem, although algorithms implemented in C would be faster. Strength: Passwords are [very] weak, especially if of the 6-10 alphanumeric variety. True secret keys where all bit combinations are used is stronger. Entering passwords has been mentioned but I believe only passwords were assumed. It is better to not provide any encryption than to lure novices into believing they are secure when they are not. Algorithms: Be sure to choose good ones and allow for changing later. Key distribution: How to distribute secret keys beyond a small group of friends is problematic. In short it doesn't scale. Looking to public-private key pairs can be equally problematic. This can get you into encryption certs, but *how* you use them correctly differs from signing certs. More on this later if you want. ZIP: Look beyond just zip files. A scheme that works for any/all files in the distribution, not just ZIPs, would be better. (IIRC there have been problems with encrypted zips, but that was years ago. Those issues may have been fixed.) Short version: Doing this right is hard. Simply supporting a password based ZIP file is, in my opinion, not real protection. Gotta go. Later. Larry ___ 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] Support for Encrypted Zip as python scripts
On Mon, Aug 24, 2009 at 11:52 AM, Bugbee, Larry wrote: > I like the idea, but... For what use case? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Support for Encrypted Zip as python scripts
> > I like the idea, but... > For what use case? I don't have a specific case in mind. In general, however, it would be nice to be able to protect intellectual property, but without addressing the problem from a holistic view, there is little protection afforded and perhaps a lot of unrewarded work. And I forgot one, Distribution of crypto across certain international borders. Export/import laws by itself can be a showstopper. ___ 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] Support for Encrypted Zip as python scripts
Bugbee, Larry wrote: >>> I like the idea, but... >> For what use case? > > I don't have a specific case in mind. In general, however, it would be > nice to be able to protect intellectual property This I'm also unclear about. How does it protect intellectual property? Won't the person running the zipfile have to enter the password? Whom would you protect the IP from? 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] Support for Encrypted Zip as python scripts
On Mon, Aug 24, 2009 at 2:01 PM, Bugbee, Larry wrote: > I don't have a specific case in mind. In general, however, it would be > nice to be able to protect intellectual property, but without addressing > the problem from a holistic view, there is little protection afforded > and perhaps a lot of unrewarded work. I would think just distributing pyc files would achieve that goal ___ 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] Support for Encrypted Zip as python scripts
I like the idea, but... >>> For what use case? >> I don't have a specific case in mind. In general, however, it >> would be nice to be able to protect intellectual property > This I'm also unclear about. How does it protect intellectual > property? Won't the person running the zipfile have to enter the > password? Whom would you protect the IP from? I agree the IP will have to be exposed at some point to be useful, but let's not overlook other things that could be in play like PIA agreements and the like. Also, something stronger than a password will be needed to be secure, and secret key distribution does not scale. There is a lot more to consider and we are only scratching the surface. Confidentiality in-the-large will take far more than encrypted ZIP files. Please know that I am not pushing for the encryption of ZIP files and this thread is going down a path I did not intend, or desire pursuing. My original post was intended to increase the awareness in those thinking encrypted ZIP files will 1) be easy, 2) afford the protection they desire, and 3) not lead others into a sense of false security. Encryption sounds good, but doing it right can be a landmine. A quick fix to support ZIP files will likely create more problems than it will solve. I still say it would be *nice* if there was some way to protect IP. I have no expectations that it will be easy, and least of all, solved by encrypted ZIP files and a simple patch to Python. ...but that should not diminish the desire. Larry ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Good evening fellow Pythonistas,
Considering a PEP is now available I'd like to join this discussion and
raise several points with regard to both the PEP and the ipaddr reference
implementation put forward with it.
1) Firstly, an offering of code.
I'd like to bring to your attention an example implementation of an IP
address library and interface for general discussion to compare and contrast
with ipaddr 2.0.x :-
http://netaddr.googlecode.com/svn/branches/exp_0.7.x_ip_only
It is based on netaddr 0.7.2 which I threw together earlier today.
In essence, I've stripped out all of what could be considered non-essential
code for a purely IP related library. This branch should be suitable for
*theoretical* consideration of inclusion into some future version of the
Python standard library (with a little work).
It is a pure subset of netaddr release 0.7.2, *minus* the following :-
- all IEEE layer-2 code
- some fairly non-essential IANA IP data files and lookup code
- IP globbing code (fairly niche)
Aside: Just a small mention here that I listened carefully to Clay McClure's
and others criticisms of the previous incarnation of ipaddr. The 0.7.x
series of netaddr breaks backward compatibility with previous netaddr
releases and is an "answer" of sorts to that discussion and issue raised
within the Python community. I hope you like what I've done with it.
For the purposes of this discussion consider this branch the "Firefox to
netaddr's Mozilla" or maybe just plain old "netaddr-ip-lite" ;-)
2) I refute bold claim in the PEP that :-
"Finding a good library for performing those tasks can be somewhat more
difficult."
On the contrary, I wager that netaddr is now a perfectly decent alternative
implementation to ipaddr, containing quite a few more features with little
of the slowness for most common operations, 2/3x faster in a lot of cases,
not that we're counting. What a difference a year makes! I also rate IPy
quite highly even if it is getting a little "long in the tooth". For a lot
of users, IPy could also be considered a nice, stable API!
By the same token I'm happy to note some convergence between the ipaddr and
netaddr's various interfaces, particularly in light of discussions and
arguments put forward by Clay McClure and others. A satisfactory compromise
between the two however still seems a way off.
3) I also disagree with the PEP's claim that :-
"attempts to combine [IPv4 and IPv6] into one object would be like
trying to force a round peg into a square hole (or vice versa)".
netaddr (and for that matter IPy) cope with this perceived problem
admirably.
netaddr employs a simple variant of the GoF Strategy design pattern (with
added Python sensibility). In the rare cases where ambiguity exists between
IPv4 and IPv6 addresses a version parameter may be passed to the constructor
of the IPAddress class to differentiate between them. Providing an IP
address version to the constructor also provides a small performance
improvement.
IPv4 and IPv6 addresses can be used interchangably throughout netaddr
without causing issue during operations such as sorting, merging (known in
the PEP as "address collapsing") or address exclusion.
Don't try and do this with the current reference implementation of ipaddr :-
>>> collapse_address_list([IPv4Address('1.1.1.1'),
IPv6Address('::1.1.1.1')])
[IPv4Network('1.1.1.1/32')]
OUCH! Even if this isn't allowed (according to the documentation), it should
raise an Exception rather than silently passing through.
I actually raised this back in May on the ipaddr bug tracker but it hasn't
received any attention so far :-
http://code.google.com/p/ipaddr-py/issues/detail?id=18
Compare this with netaddr's behaviour :-
>>> cidr_merge([IPAddress('1.1.1.1'), IPAddress('::1.1.1.1')])
[IPNetwork('1.1.1.1/32'), IPNetwork('::1.1.1.1/128')]
That's more like it.
4) It may just be me but the design of this latest incarnation of ipaddr
seems somewhat complicated for so few lines of code. Compared with ipaddr,
netaddr doesn't use or require multiple inheritance nor a seemingly
convoluted inheritance heirarchy. There isn't a need for an IP() type
'multiplexer' function either (although I might be missing an important use
case here). But, then again, this may just be my personal preference talking
here. I prefer composition over inheritance in most cases.
In netaddr, if a user wants to represent an IP address (without netmask),
they should use the IPAddress class, if they want to represent and IP
address with some form of mask, they should use the IPNetwork class.
5) The ipaddr library is also missing options for expanding various
(exceedingly common) IP abbreviations.
>>> from netaddr import IPNetwork
>>> IPNetwork('10/8', True)
IPNetwork('10.0.0.0/8')
netaddr also handles classful IP address logic, still pervasive throughout
modern IP stacks :-
>>> IPNetwork('192.168.0.1', True)
IPNetwork('192.168.0.1/24')
Note that these options are disabled by default, to keep u
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Mon, Aug 24, 2009 at 3:24 PM, DrKJam wrote: > Good evening fellow Pythonistas, > > Considering a PEP is now available I'd like to join this discussion and > raise several points with regard to both the PEP and the ipaddr reference > implementation put forward with it. Hi David, is this what passes for serious debate? there's more passive aggressive condescension in here than a teenager's diary. I'll try to respond with a little more civility than you managed (apologies, present paragraph excluded). As it was left in early June, a pep and design modifications were requested before ipaddr would be considered for inclusion, but if this is going to start *another* drawn out ipaddr/netaddr thread, perhaps the mailman admin(s) could setup a new SIG list for this. I personally hope that's not required; yours has been the only dissenting email and I believe I respond to all of your major points here. > 1) Firstly, an offering of code. > > I'd like to bring to your attention an example implementation of an IP > address library and interface for general discussion to compare and contrast > with ipaddr 2.0.x :- > > http://netaddr.googlecode.com/svn/branches/exp_0.7.x_ip_only > > It is based on netaddr 0.7.2 which I threw together earlier today. > > In essence, I've stripped out all of what could be considered non-essential > code for a purely IP related library. This branch should be suitable for > *theoretical* consideration of inclusion into some future version of the > Python standard library (with a little work). > > It is a pure subset of netaddr release 0.7.2, *minus* the following :- > > - all IEEE layer-2 code > - some fairly non-essential IANA IP data files and lookup code > - IP globbing code (fairly niche) > > Aside: Just a small mention here that I listened carefully to Clay McClure's > and others criticisms of the previous incarnation of ipaddr. The 0.7.x > series of netaddr breaks backward compatibility with previous netaddr > releases and is an "answer" of sorts to that discussion and issue raised > within the Python community. I hope you like what I've done with it. > > For the purposes of this discussion consider this branch the "Firefox to > netaddr's Mozilla" or maybe just plain old "netaddr-ip-lite" ;-) > > 2) I refute bold claim in the PEP that :- > > "Finding a good library for performing those tasks can be somewhat more > difficult." > > On the contrary, I wager that netaddr is now a perfectly decent alternative > implementation to ipaddr, containing quite a few more features with little > of the slowness for most common operations, I think you mean refuse, b/c this certainly wasn't the case when I started writing ipaddr. IPy existed, but it was far too heavyweight and restrictive for what I needed (no disrespect to the author(s) intended). I believe I've an email or two from you wherein you indicate the same. > 2/3x faster in a lot of cases, > not that we're counting. What a difference a year makes! > I also rate IPy quite highly even if it is getting a little "long in the > tooth". > For a lot of users, IPy could also be considered a nice, stable API! yes, netaddr has sped up quite a bit. It's still slower in many cases as well. But again, who's timing? > By the same token I'm happy to note some convergence between the ipaddr and > netaddr's various interfaces, particularly in light of discussions and > arguments put forward by Clay McClure and others. A satisfactory compromise > between the two however still seems a way off. > > > 3) I also disagree with the PEP's claim that :- > > "attempts to combine [IPv4 and IPv6] into one object would be like > trying to force a round peg into a square hole (or vice versa)". > > netaddr (and for that matter IPy) cope with this perceived problem > admirably. > > netaddr employs a simple variant of the GoF Strategy design pattern (with > added Python sensibility). In the rare cases where ambiguity exists between > IPv4 and IPv6 addresses a version parameter may be passed to the constructor > of the IPAddress class to differentiate between them. Providing an IP > address version to the constructor also provides a small performance > improvement. I'm not sure what point you're trying to make here. I didn't say it was impossible, I inferred that there are easier ways. having used code which crams both types into one object, I found it to be cludgey and complicated so I designed something different. and as a hardly partial observer, I'll add the explicit address version you can pass to the IPAddress class, but not the IPNetwork class, is, odd. it actually seems to slow down object creation (~5%) except in the case of an int arg (your default is about twice as slow). > IPv4 and IPv6 addresses can be used interchangably throughout netaddr > without causing issue during operations such as sorting, merging (known in > the PEP as "address collapsing") or address exclusion. > > Don't try and do this with the current reference implementat
Re: [Python-Dev] Support for Encrypted Zip as python scripts
Bugbee, Larry writes: > My original post was intended to increase the awareness in those > thinking encrypted ZIP files will 1) be easy, 2) afford the > protection they desire, and 3) not lead others into a sense of > false security. All good points, but note that (even without the DMCA) at least in the U.S. copyright law provides for *criminal* penalties for willful infringement. If you needed to type in a password to copy, you can't argue "I didn't know this was private property", just as crossing a fence is stronger evidence of criminal trespass than ignoring "Posted" signs. For patents, the password prompt could notice of patent protection, with similar effect of strengthening penalties for infringing. So even weak encryption strengthens the available legal protection. That is not sufficient reason to consider putting encrypted zips or anything similar into the stdlib. It's relevant to users' decisions should such features become available, that's all. > I still say it would be *nice* if there was some way to protect IP. -1. Intellectual assets *can* give benefits with zero further costs of production and almost negligible costs of distribution. But IP, like any other property that requires a temporary transfer of possession to give economic benefit (eg, rental cars), is going to involve substantial transaction cost for consumers (search for the product, license negotiation[1]), as well as the usual excess burden of monopoly. The current state where only legal protection is feasible is arguably a good compromise. Since it involves substantial costs of enforcement borne by the rightsholder, it's only going to be invoked where the total social benefit (net consumer value plus vendor profit) is large enough to swamp the small transaction costs. I think that Python should spend zero effort on implementing technical means of IP protection. Any side effects of privacy protection devices should be more than enough to serve. Regards, Footnotes: [1] Not necessarily bargaining, but also including studying the terms of take it or leave it offers, etc. ___ 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
