Re: [Python-Dev] Mercurial migration: help needed

[Martin v. Löwis]

>>>  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.

I have no opinion on that.

> * 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.

Yes. The functionality being discussed should not be added to win32text.

> Assuming I am correct, I am inclined to agree - win32text may be "good
> enough" in the short term, but it is far from ideal.

I also feel that an extension that is inherently platform independent
and has a clear specification has much higher chances of becoming a
standard feature of Mercurial one day.

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

[Martin v. Löwis]

> 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

That certainly won't happen. python-dev, as a community, has never ever
taken ownership of anything. It's always individuals who take ownership.

So you essentially say that you want somebody else (but not you) take
ownership - which, of course, is certainly fine. Hence my call for
volunteers.

> 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...

My prediction is that it will depend on whether workable code is
available by the time a decision is made to migrate. If code is
available, then migration will happen (no matter whether the code
has an owner); if no code is available, migration will stall.

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

[Python-Dev] Support for Encrypted Zip as python scripts

[Shashank Singh]

There is an interesting suggestion (http://bugs.python.org/issue6749).
to add support to run encrypted zip files as python scripts.

No doubt this is a useful functionality to have but it would be great to
have some comments on whether
this can be(or even should be) feasibly added as an inbuilt support.

-- 
Regards
Shashank Singh
Senior Undergraduate, Department of Computer Science and Engineering
Indian Institute of Technology Bombay
shashank.sunny.si...@gmail.com
http://www.cse.iitb.ac.in/~shashanksingh
___
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

[Guido van Rossum]

On Sun, Aug 23, 2009 at 9:09 AM, Shashank
Singh wrote:
> There is an interesting suggestion (http://bugs.python.org/issue6749).
> to add support to run encrypted zip files as python scripts.
>
> No doubt this is a useful functionality to have but it would be great to
> have some comments on whether
> this can be(or even should be) feasibly added as an inbuilt support.

MvL already asked for a patch so I suppose that means he thinks it's
useful. Personally I've never encountered an encrypted zipfile, so I
just have questions: is there a standard encryption algorithm? What is
encrypted? The entire file or individual members? How are you supposed
to give the password? 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).

-- 
--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

[Brett Cannon]

There is a standard for encrypting entire zip files. And I was looking at
the zip docs the other day and zipfile can already decrypt but not encrypt
(assuming my memory is accurate; doing this from my phone on vacation).

On Aug 23, 2009 2:10 PM, "Guido van Rossum"  wrote:

On Sun, Aug 23, 2009 at 9:09 AM, Shashank Singh<
shashank.sunny.si...@gmail.com> wrote: > There is an...
MvL already asked for a patch so I suppose that means he thinks it's
useful. Personally I've never encountered an encrypted zipfile, so I
just have questions: is there a standard encryption algorithm? What is
encrypted? The entire file or individual members? How are you supposed
to give the password? 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).

--
--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/brett%40python.org
___
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

[Guido van Rossum]

> On Aug 23, 2009 2:10 PM, "Guido van Rossum"  wrote:
> MvL already asked for a patch so I suppose that means he thinks it's
> useful. Personally I've never encountered an encrypted zipfile, so I
> just have questions: is there a standard encryption algorithm? What is
> encrypted? The entire file or individual members? How are you supposed
> to give the password? 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).

On Sun, Aug 23, 2009 at 1:24 PM, Brett Cannon wrote:
> There is a standard for encrypting entire zip files. And I was looking at
> the zip docs the other day and zipfile can already decrypt but not encrypt
> (assuming my memory is accurate; doing this from my phone on vacation).

Ah, cool. Then the only issue for the patch presumably is an API to
provide the password. Passing it as a command-line flag seems very
insecure (though in some cases there may be no choice), so presumably
it needs to be prompted and read from stdin. (Though it appears from
skimming zipfile.py that it support encrypted individual archive
members, not the zipfile as a whole. Also the docs mention that
decryption is "extremely slow as it is implemented in native python
rather than C.")

Anyway it looks like if someone wants to try this, only the code in
runpy.py needs to be touched.

-- 
--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

[Martin v. Löwis]

>> No doubt this is a useful functionality to have but it would be great to
>> have some comments on whether
>> this can be(or even should be) feasibly added as an inbuilt support.
> 
> MvL already asked for a patch so I suppose that means he thinks it's
> useful.

I am actual skeptical that it is implementable in a reasonable way;
if implemented, I'd say: why not?

> Personally I've never encountered an encrypted zipfile, so I
> just have questions: is there a standard encryption algorithm?

In principle, yes. There are several aspects of encryption described in

http://www.pkware.com/documents/casestudies/APPNOTE.TXT

There are several encryption algorithms defined, such as
"traditional PKWARE", DES, 3DES, "original RC2", RC4, AES,
"corrected RC2", "corrected RC2-64", blowfish, twofish. 

In the file header general purpose bits , bit 0 indicates "file is
encrypted" (which means "traditional PKWARE"), bit 6 indicates "strong
encryption" (an additional header then giving details).

> What is encrypted? The entire file or individual members?

Traditionally, only individual files. With strong encryption (only?),
the central directory can also be encrypted.

> How are you supposed to give the password?

In pkzip: interactively. In the import support: this remains to be seen
in the patch. I assume people requesting that feature have a plan.

> 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).

The zipfile module already supports decryption. I forgot whether we
determined that support for decryption only doesn't fall under the
export restrictions, or whether we reported the module to the BXA as
well.

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

[Gregory P. Smith]

On Sun, Aug 23, 2009 at 2:24 PM, "Martin v. Löwis" wrote:

> >> No doubt this is a useful functionality to have but it would be great to
> >> have some comments on whether
> >> this can be(or even should be) feasibly added as an inbuilt support.
> >
> > MvL already asked for a patch so I suppose that means he thinks it's
> > useful.
>
> I am actual skeptical that it is implementable in a reasonable way;
> if implemented, I'd say: why not?
>
> > Personally I've never encountered an encrypted zipfile, so I
> > just have questions: is there a standard encryption algorithm?
>
> In principle, yes. There are several aspects of encryption described in
>
> http://www.pkware.com/documents/casestudies/APPNOTE.TXT
>
> There are several encryption algorithms defined, such as
> "traditional PKWARE", DES, 3DES, "original RC2", RC4, AES,
> "corrected RC2", "corrected RC2-64", blowfish, twofish.
>
> In the file header general purpose bits , bit 0 indicates "file is
> encrypted" (which means "traditional PKWARE"), bit 6 indicates "strong
> encryption" (an additional header then giving details).
>
> > What is encrypted? The entire file or individual members?
>
> Traditionally, only individual files. With strong encryption (only?),
> the central directory can also be encrypted.
>
> > How are you supposed to give the password?
>
> In pkzip: interactively. In the import support: this remains to be seen
> in the patch. I assume people requesting that feature have a plan.
>
> > 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).
>
> The zipfile module already supports decryption. I forgot whether we
> determined that support for decryption only doesn't fall under the
> export restrictions, or whether we reported the module to the BXA as
> well.
>

I doubt you can even classify the zipfile module's "decryption" support as
encryption.  It is trivially stupid, easily cracked (a 32bit crc based
"cipher").  The zipfile module does not support the various later encryption
schemes that use actual crypto algorithms.

I do not think we should support execution of python scripts or importing of
modules from encrypted zips.  I do not see a valid use case.

-gps
___
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

[Guido van Rossum]

On Sun, Aug 23, 2009 at 5:59 PM, Gregory P. Smith wrote:
> I doubt you can even classify the zipfile module's "decryption" support as
> encryption.  It is trivially stupid, easily cracked (a 32bit crc based
> "cipher").  The zipfile module does not support the various later encryption
> schemes that use actual crypto algorithms.

Oops. I guess this is what Martin called "traditional PKWARE".

Quite separate from the current thread it might make sense to support
the stronger encryption schemes in zipfile.

> I do not think we should support execution of python scripts or importing of
> modules from encrypted zips.  I do not see a valid use case.

I am still awaiting a use case too (for running an encrypted script).
I notice that the OP hasn't replied yet. Let's give them a chance. (I
added Shashank back to the thread just in 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

[Nick Coghlan]

Guido van Rossum wrote:
> Anyway it looks like if someone wants to try this, only the code in
> runpy.py needs to be touched.

The necessary work would actually be in zipimport. runpy doesn't know
anything about the details of where the module code comes from, it just
asks the relevant importer for the details. For zipfile and directory
execution, they get added to the start of sys.path and then runpy is
invoked to look for the module "__main__". From that point on most of
the heavy lifting is handled by the regular import machinery (aside from
using the pkgutil emulation for the basic import behaviour that isn't
fully exposed by the imp module).

I added a -1 to the tracker issue as well. That's due both to my opinion
on the inherent idiocy of DRM though (since shared secrets don't provide
any security when the attacker in your threat model is one of the people
you are sharing the secret with) and to the fact that associating
passwords with the relevant zipfile entries on sys.path would get messy
fairly quickly.

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

[Shashank Singh]

On Mon, Aug 24, 2009 at 7:39 AM, Nick Coghlan  wrote:

> Guido van Rossum wrote:
> > Anyway it looks like if someone wants to try this, only the code in
> > runpy.py needs to be touched.
>
> The necessary work would actually be in zipimport. runpy doesn't know
> anything about the details of where the module code comes from, it just
> asks the relevant importer for the details. For zipfile and directory
> execution, they get added to the start of sys.path and then runpy is
> invoked to look for the module "__main__". From that point on most of
> the heavy lifting is handled by the regular import machinery (aside from
> using the pkgutil emulation for the basic import behaviour that isn't
> fully exposed by the imp module).
>
> I added a -1 to the tracker issue as well. That's due both to my opinion
> on the inherent idiocy of DRM though (since shared secrets don't provide
> any security when the attacker in your threat model is one of the people
> you are sharing the secret with) and to the fact that associating
> passwords with the relevant zipfile entries on sys.path would get messy
> fairly quickly.
>
> 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/shashank.sunny.singh%40gmail.com
>



-- 
Regards
Shashank Singh
Senior Undergraduate, Department of Computer Science and Engineering
Indian Institute of Technology Bombay
shashank.sunny.si...@gmail.com
http://www.cse.iitb.ac.in/~shashanksingh
___
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

[Shashank Singh]

oops..sorry for the empty mail :P

On Mon, Aug 24, 2009 at 8:09 AM, Shashank Singh <
shashank.sunny.si...@gmail.com> wrote:

>
>
> On Mon, Aug 24, 2009 at 7:39 AM, Nick Coghlan  wrote:
>
>> Guido van Rossum wrote:
>> > Anyway it looks like if someone wants to try this, only the code in
>> > runpy.py needs to be touched.
>>
>> The necessary work would actually be in zipimport. runpy doesn't know
>> anything about the details of where the module code comes from, it just
>> asks the relevant importer for the details. For zipfile and directory
>> execution, they get added to the start of sys.path and then runpy is
>> invoked to look for the module "__main__". From that point on most of
>> the heavy lifting is handled by the regular import machinery (aside from
>> using the pkgutil emulation for the basic import behaviour that isn't
>> fully exposed by the imp module).
>
>

That is where I see the problem in creating a natural approach. Correct me
if I am wrong here but since runpy doesn't  know anything about the script
being a zip file to add such a support we will have to break the current
delegation mechanism and bring runpy in the loop too.

Also, since a zip file is automatically checked for (I believe there are no
switches to
specify that the script is a zip) will it not be a two trip mechanism: You
naively try
a to run a zip; get an error (say ERR_ZIP_ENCRYPTED) and then ask for
password?



>
>>
>> I added a -1 to the tracker issue as well. That's due both to my opinion
>> on the inherent idiocy of DRM though (since shared secrets don't provide
>> any security when the attacker in your threat model is one of the people
>> you are sharing the secret with) and to the fact that associating
>> passwords with the relevant zipfile entries on sys.path would get messy
>> fairly quickly.
>>
>> 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/shashank.sunny.singh%40gmail.com
>>
>
>
>
> --
> Regards
> Shashank Singh
> Senior Undergraduate, Department of Computer Science and Engineering
> Indian Institute of Technology Bombay
> shashank.sunny.si...@gmail.com
> http://www.cse.iitb.ac.in/~shashanksingh
>



-- 
Regards
Shashank Singh
Senior Undergraduate, Department of Computer Science and Engineering
Indian Institute of Technology Bombay
shashank.sunny.si...@gmail.com
http://www.cse.iitb.ac.in/~shashanksingh
___
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

[Guido van Rossum]

OMG, the use case is actually running a script without giving the user
access to the script's source? Agreed that's a big -1.

I thought it was just for running a zip containing code so secret you
don't want to leave it around on your hard drive without encryption
(say, the program you use to compute your employee's bonuses, or
perhaps a patented algoritm for detecting spam). That use case would
make a small amount of sense, though I personally don't care enough to
write the code to support it.

--Guido

On Sun, Aug 23, 2009 at 7:09 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Anyway it looks like if someone wants to try this, only the code in
>> runpy.py needs to be touched.
>
> The necessary work would actually be in zipimport. runpy doesn't know
> anything about the details of where the module code comes from, it just
> asks the relevant importer for the details. For zipfile and directory
> execution, they get added to the start of sys.path and then runpy is
> invoked to look for the module "__main__". From that point on most of
> the heavy lifting is handled by the regular import machinery (aside from
> using the pkgutil emulation for the basic import behaviour that isn't
> fully exposed by the imp module).
>
> I added a -1 to the tracker issue as well. That's due both to my opinion
> on the inherent idiocy of DRM though (since shared secrets don't provide
> any security when the attacker in your threat model is one of the people
> you are sharing the secret with) and to the fact that associating
> passwords with the relevant zipfile entries on sys.path would get messy
> fairly quickly.

-- 
--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] Mercurial migration: help needed

[Mark Hammond]

On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:

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


That certainly won't happen. python-dev, as a community, has never ever
taken ownership of anything. It's always individuals who take ownership.


I believe ownership of a task and ownership of a cause are somewhat 
different.


In other words, I'm happy to take ownership of a number as tasks 
relating to this cause, but if the general feeling is that it is my 
cause rather than *our* cause, then I will probably opt-out - I'm taking 
these tasks on at this moment purely because I believe it *is* a common 
cause.



So you essentially say that you want somebody else (but not you) take
ownership - which, of course, is certainly fine. Hence my call for
volunteers.


Hence my volunteering and the time I am currently spending.


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...


My prediction is that it will depend on whether workable code is
available by the time a decision is made to migrate. If code is
available, then migration will happen (no matter whether the code
has an owner); if no code is available, migration will stall.


Right - I guess we are all still struggling with exactly what "workable 
code" means in this context.


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

[Nick Coghlan]

Mark Hammond wrote:
> On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
>>> 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
>>
>> That certainly won't happen. python-dev, as a community, has never ever
>> taken ownership of anything. It's always individuals who take ownership.
> 
> I believe ownership of a task and ownership of a cause are somewhat
> different.
> 
> In other words, I'm happy to take ownership of a number as tasks
> relating to this cause, but if the general feeling is that it is my
> cause rather than *our* cause, then I will probably opt-out - I'm taking
> these tasks on at this moment purely because I believe it *is* a common
> cause.

If by ownership of the cause you just mean "acceptable handling of line
conversions" as being one of the criteria that must be dealt with before
the switch to hg actually happens, then I think you have that agreement
already.

We're not going to accept a regression in line handling from what SVN
provides. Your proposed improvements to win32text (possibly in the form
of a new extension based on win32text rather than a new version of
win32text itself) along with server side enforcement sound like they
will meet the need.

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

[Nick Coghlan]

Guido van Rossum wrote:
> OMG, the use case is actually running a script without giving the user
> access to the script's source? Agreed that's a big -1.
> 
> I thought it was just for running a zip containing code so secret you
> don't want to leave it around on your hard drive without encryption
> (say, the program you use to compute your employee's bonuses, or
> perhaps a patented algoritm for detecting spam). That use case would
> make a small amount of sense, though I personally don't care enough to
> write the code to support it.

Actually, the issue posting doesn't say either way - it doesn't provide
any real use cases at all.

For local protection of confidential information there are already much
better solutions out there (e.g. whole disk encryption, OS file
permissions, OS folder encryption), so a poor-man's DRM was the only
remaining remotely plausible use case I could see (and that's a bad idea
for all the reasons that DRM is almost always a bad idea).

Now, that could just be a failure of imagination on my part, but genuine
use case suggestions for the feature have been non existent so far.

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

[Shashank Singh]

A litle off topic but the zipfile doc says: "Decryption is extremely slow as
it
is implemented in native python rather than C".

Why is this limitation there? I mean, is there any specific reason for not
implementing
it in C?

On Mon, Aug 24, 2009 at 8:45 AM, Nick Coghlan  wrote:

> Guido van Rossum wrote:
> > OMG, the use case is actually running a script without giving the user
> > access to the script's source? Agreed that's a big -1.
> >
> > I thought it was just for running a zip containing code so secret you
> > don't want to leave it around on your hard drive without encryption
> > (say, the program you use to compute your employee's bonuses, or
> > perhaps a patented algoritm for detecting spam). That use case would
> > make a small amount of sense, though I personally don't care enough to
> > write the code to support it.
>
> Actually, the issue posting doesn't say either way - it doesn't provide
> any real use cases at all.
>
> For local protection of confidential information there are already much
> better solutions out there (e.g. whole disk encryption, OS file
> permissions, OS folder encryption), so a poor-man's DRM was the only
> remaining remotely plausible use case I could see (and that's a bad idea
> for all the reasons that DRM is almost always a bad idea).
>
> Now, that could just be a failure of imagination on my part, but genuine
> use case suggestions for the feature have been non existent so far.
>
> 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/shashank.sunny.singh%40gmail.com
>



-- 
Regards
Shashank Singh
Senior Undergraduate, Department of Computer Science and Engineering
Indian Institute of Technology Bombay
shashank.sunny.si...@gmail.com
http://www.cse.iitb.ac.in/~shashanksingh
___
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

[Guido van Rossum]

Because it is easier to write in Python, and (as Greg explained) the
encryption is so lousy that you're unlikely to find heavy use of it.
Therefore nobody (so far) has cared to write an accelerator in C.

On Sun, Aug 23, 2009 at 9:23 PM, Shashank
Singh wrote:
> A litle off topic but the zipfile doc says: "Decryption is extremely slow as
> it
> is implemented in native python rather than C".
>
> Why is this limitation there? I mean, is there any specific reason for not
> implementing
> it in C?
>
> On Mon, Aug 24, 2009 at 8:45 AM, Nick Coghlan  wrote:
>>
>> Guido van Rossum wrote:
>> > OMG, the use case is actually running a script without giving the user
>> > access to the script's source? Agreed that's a big -1.
>> >
>> > I thought it was just for running a zip containing code so secret you
>> > don't want to leave it around on your hard drive without encryption
>> > (say, the program you use to compute your employee's bonuses, or
>> > perhaps a patented algoritm for detecting spam). That use case would
>> > make a small amount of sense, though I personally don't care enough to
>> > write the code to support it.
>>
>> Actually, the issue posting doesn't say either way - it doesn't provide
>> any real use cases at all.
>>
>> For local protection of confidential information there are already much
>> better solutions out there (e.g. whole disk encryption, OS file
>> permissions, OS folder encryption), so a poor-man's DRM was the only
>> remaining remotely plausible use case I could see (and that's a bad idea
>> for all the reasons that DRM is almost always a bad idea).
>>
>> Now, that could just be a failure of imagination on my part, but genuine
>> use case suggestions for the feature have been non existent so far.
>>
>> 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/shashank.sunny.singh%40gmail.com
>
>
>
> --
> Regards
> Shashank Singh
> Senior Undergraduate, Department of Computer Science and Engineering
> Indian Institute of Technology Bombay
> shashank.sunny.si...@gmail.com
> http://www.cse.iitb.ac.in/~shashanksingh
>
> ___
> 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/guido%40python.org
>
>



-- 
--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