PEP 376

[Tarek Ziadé]

Hello,

I would like to propose this PEP for inclusion into Python 2.7 / 3.2

http://www.python.org/dev/peps/pep-0376/

It has been discussed a lot already in the distutils-SIG, but new
feedbacks are welcome

there's an implementation prototype here :
http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py

Regards
Tarek

 

[Carl Banks]

Hello,

I would like to propose this PEP for inclusion into Python 2.7 / 3.2

http://www.python.org/dev/peps/pep-0376/

It has been discussed a lot already in the distutils-SIG, but new
feedbacks are welcome

there's an implementation prototype here :http://bitbucket.org/tarek/pep376/src/tip/pkgutil.py

+1

This seems to be a well-designed solution that corrects the ad-hoc-
ness of installation while keeping its effects on existing tools
small.

I hate those egg-info files but I would be very happy if they'd at
least always be in an accounted-for place. Maybe I'd even consider
making use of them some day.

As for setuptools, I'm sure it will accommodate the change and
probably improve itself in the process. (And if the setuptools
doesn't change then some other tool will grow into its niche; either
way it'd be an improvement.)


Carl Banks

 

[Tarek Ziadé]

+1

This seems to be a well-designed solution that corrects the ad-hoc-
ness of installation while keeping its effects on existing tools
small.

I hate those egg-info files but I would be very happy if they'd at
least always be in an accounted-for place.  Maybe I'd even consider
making use of them some day.

As for setuptools, I'm sure it will accommodate the change and
probably improve itself in the process.  (And if the setuptools
doesn't change then some other tool will grow into its niche; either
way it'd be an improvement.)

Yes exactly, the plan is to try to make distutils a reference layer
for third party package managers
and if possible to become a "smaller" package later on the road.

Cheers
Tarek

 

[Lawrence D'Oliveiro]

I would like to propose this PEP for inclusion into Python 2.7 / 3.2

http://www.python.org/dev/peps/pep-0376/

Why are you using MD5?

 

[Carl Banks]

Why are you using MD5?

I doubt it's the design aim for eggs to be cryptographically secure,
and MD5 is sufficient to detect changes.

Carl Banks

 

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

I doubt it's the design aim for eggs to be cryptographically secure,
and MD5 is sufficient to detect changes.

Even so, choosing md5 in 2009 for something that (hopefully) will be
used in years is a bad design decision. It creates a dependency for to
an algorithm that all sensible recommendations point you to move away
from. Just check hashlib documentation for example:

http://docs.python.org/library/hashlib.html

I would suggest to use the SHA-256 in the library. The reason for this
is that md5 and SHA-1 are weak. The computational complexity of SHA-256
is bigger, but since it probably wont be done many thousands of times
during an egg installation, it shouldn't add a noticable delay.

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpK1dgACgkQZoPr8HT30QEwRACg0vhO6TO1k0Pesm5qQOJVen/H
vxwAoKdNZZkrDvm/CtQVbr0kZog0sX/U
=Frss
-----END PGP SIGNATURE-----

 

[Paul Rubin]

http://docs.python.org/library/hashlib.html
I would suggest to use the SHA-256 in the library.

I agree with this. We should even move towards supporting x509 and/or
gpg signatures in eggs, similar to signed .jar files.

 

[Richard Brodie]

Even so, choosing md5 in 2009 for something that (hopefully) will be
used in years is a bad design decision. It creates a dependency for to
an algorithm that all sensible recommendations point you to move away
from.

Why not write the field as algorithm:value?

e.g. sha1:8590b685654367e3eba70dc00df7e45e88c21da4

Installers can fallback to using hashlib.new(), so you can plug in a new
algorithm without changing the PEP or the installer code.

 

[Paul Rubin]

Why not write the field as algorithm:value?
e.g. sha1:8590b685654367e3eba70dc00df7e45e88c21da4

This is reasonable, though I would deprecate md5 and sha1 already, and
start with sha256.

 

[ELLINGHAUS, LANCE]

Does anyone have any code that would allow setting the desktop background image under Windows XP?

Thank you,
lance


Lance Ellinghaus
mailto:[email protected]

 

[alex23]

Does anyone have any code that would allow setting the desktop background image under Windows XP?

It's amazing what typing "python windows desktop" into Google will
find you:

http://snippets.dzone.com/posts/show/3348

Any other searches you'd like us to do?

(Also: please post a new message instead of replying to an existing
one and changing the subject, it screws up threading)

 

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

Why not write the field as algorithm:value?

e.g. sha1:8590b685654367e3eba70dc00df7e45e88c21da4

Installers can fallback to using hashlib.new(), so you can plug in a new
algorithm without changing the PEP or the installer code.

+1

Good idea and future proof as well as being simple.

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMaFoACgkQZoPr8HT30QHVxQCfWqKprUaAQxaxTfYJVfIp8+FC
5UIAn2cWNoMe+sdNO4BSZG7e+19qkqvl
=Id7s
-----END PGP SIGNATURE-----

 

[Tarek Ziadé]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!



+1

Good idea and future proof as well as being simple.

The prefix is a good idea but since it's just a checksum to control
that the file hasn't changed
what's wrong with using a weak hash algorithm like md5 or now sha1 ?

If someone wants to modify a file of a distribution he can recreate
the checksum as well,
the only secured way to prevent that would be to use gpg keys but
isn't that overkill for what we need ?

e.g. making sure a file wasn't modified when distutils uninstalls a
distribution.

Tarek

 

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

The prefix is a good idea but since it's just a checksum to control
that the file hasn't changed
what's wrong with using a weak hash algorithm like md5 or now sha1 ?

Because it creates a dependency to an old algorithm that should be
deprecated. Also using MD5, even for a thing like this might make people
belive that it is an ok algorithm to use - "Hey, it is used by the
default install in Python, so it must be ok, right?"

If we flip the argument around: Why would you want to use MD5 instead of
SHA-256? For the specific use case the performance will not (should not)
be an issue.

As I wrote a few mails ago, it is time to move forward from MD5 and
designing something in 2009 that will be around for many years that uses
MD5 is (IMHO) a bad design decision.

If someone wants to modify a file of a distribution he can recreate
the checksum as well,
the only secured way to prevent that would be to use gpg keys but
isn't that overkill for what we need ?

Actually, adding this type of security would IMHO be a good idea.

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMsuYACgkQZoPr8HT30QELagCghfYyHyK5jnkS8DlaQ2ZX4KR8
W+YAniWSvWRvm47/xGu0thTaYioETY94
=2x3X
-----END PGP SIGNATURE-----

 

[Lie Ryan]

Aloha!


Because it creates a dependency to an old algorithm that should be
deprecated. Also using MD5, even for a thing like this might make people
belive that it is an ok algorithm to use - "Hey, it is used by the
default install in Python, so it must be ok, right?"

If we flip the argument around: Why would you want to use MD5 instead of
SHA-256? For the specific use case the performance will not (should not)
be an issue.

As I wrote a few mails ago, it is time to move forward from MD5 and
designing something in 2009 that will be around for many years that uses
MD5 is (IMHO) a bad design decision.


Actually, adding this type of security would IMHO be a good idea.

Now, are we actually talking about security or checksum?

It has been known for years that MD5 is weak, weak, weak. Not just in
the recent years. But it doesn't matter since MD5 was never designed for
security, MD5 was designed to protect against random bits corruption. If
you want security, look at least to GPG. For data protection against
intentional, malicious forging, definitely MD5 is the wrong choice. But
when you just want a simple checksum to ensure that a faulty router
somewhere in the internet backbone doesn't destroying your data, MD5 is
a fine algorithm.

 

[Charles Yeomans]

Now, are we actually talking about security or checksum?

It has been known for years that MD5 is weak, weak, weak. Not just in
the recent years. But it doesn't matter since MD5 was never designed
for
security, MD5 was designed to protect against random bits
corruption. If
you want security, look at least to GPG. For data protection against
intentional, malicious forging, definitely MD5 is the wrong choice.
But
when you just want a simple checksum to ensure that a faulty router
somewhere in the internet backbone doesn't destroying your data, MD5
is
a fine algorithm.
--

On the contrary, MD5 was intended to be a cryptographic hash function,
not a checksum.

Charles Yeomans

 

[Tarek Ziadé]

Ok here's my proposal for the checksum :

- I'll add the "hash_type:" suffix in the record file

- install will get a new option to define what hash should be used
when writing the RECORD file
it will default to SHA1 for 2.7/3.2

- pkgutil, that reads the RECORD files, will pick the right hash
function by looking at the suffix

now for the security it's another story that goes beyond the scope of this PEP
notice though, that the PEP provides a place-holder for distributions metadata,
so it could host a key later on.

 

[Lawrence D'Oliveiro]

On the contrary, MD5 was intended to be a cryptographic hash function,
not a checksum.

Just like MD4 and MD2 before it. They have long since been considered
worthless, and now MD5 has joined them.