[ python-Bugs-968430 ] error flattening complex smime signed message
Bugs item #968430, was opened at 2004-06-07 22:34 Message generated for change (Comment added) made by shevek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) Assigned to: Nobody/Anonymous (nobody) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem -- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 12:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106694 ] split() takes no keyword arguments
Bugs item #1106694, was opened at 2005-01-21 14:30
Message generated for change (Comment added) made by calvin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470
Category: Python Interpreter Core
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Vinz (boukthor)
Assigned to: Nobody/Anonymous (nobody)
Summary: split() takes no keyword arguments
Initial Comment:
I'm running python 2.4 on a Linux box (Mandrake cooker
10.2).
Since the string functions have been implemented as
method of string instances, there's little use for the
string module (except for constants). However, the
behaviour of the 'split' method is slightly different
from the one in the string module : it does not accept
keyword arguments.
This is annoying because the default separator argument
('any whitespace') cannot be provided manually (at
least I couldn't find a way to do it) and that means
that you can not use the default separator while
specifying a maxsplit argument (if you specify
maxsplit, you need to give a separator manually because
it comes first in the arg list), unless you use
"string.split" (and "import string") syntax.
Examples :
>>> "foo bar\tbaz\nqux".split()
['foo', 'bar', 'baz', 'qux']
>>> string.split("foo bar\tbaz\nqux")
['foo', 'bar', 'baz', 'qux']
>>> "foo bar\tbaz\nqux".split(" \t\n") # this is ok,
just illustrating that you cannot emulate the default
behaviour if you provide a separator manually
['foo bar\tbaz\nqux']
>>> string.split("foo bar\tbaz\nqux", maxsplit=2) #
what I want to do
['foo', 'bar', 'baz\nqux']
>>> "foo bar\tbaz\nqux".split(maxsplit=2) # what I get
Traceback (most recent call last):
File "", line 1, in ?
TypeError: split() takes no keyword arguments
>>> "foo bar\tbaz\nqux".split(2) # cannot skip the sep arg
Traceback (most recent call last):
File "", line 1, in ?
TypeError: expected a character buffer object
--
Comment By: Wummel (calvin)
Date: 2005-01-24 13:34
Message:
Logged In: YES
user_id=9205
Specifying None as separator gives you (as documented) the
split-on-mulitple-whitespace behaviour. This applies to both
string.split() and the split() string method. So skipping
the separator arg is not needed.
However, I agree to your wish that the string method split()
should accept the "maxsplit" as a keyword argument. It is
more backward compatible to the old string.split() function
that way.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106694&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106572 ] os.makedirs() ignores mode parameter
Bugs item #1106572, was opened at 2005-01-21 10:42
Message generated for change (Comment added) made by calvin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.makedirs() ignores mode parameter
Initial Comment:
os.makedirs('foo/x', 0777) does not create the directories
with permissions g+rwx,u+rwx,o+rwx but instead:
>>> import os
>>> os.makedirs('foo/xx', 0777)
>>>
[2]+ Stopped python2.3
[EMAIL PROTECTED]:~/sandboxes/haufecms/instance/Products/HaufeCMS:
ls -la foo
insgesamt 12
drwxr-xr-x 3 ajung ajung 4096 2005-01-21 10:39 .
drwxr-xr-x 19 ajung ajung 4096 2005-01-21 10:39 ..
drwxr-xr-x 2 ajung ajung 4096 2005-01-21 10:39 xx
This happens with Python 2.3.4 on Linux
--
Comment By: Wummel (calvin)
Date: 2005-01-24 13:48
Message:
Logged In: YES
user_id=9205
What is the current process umask? The resulting directory
mode will always be (mode & ~umask & 0777).
To be sure that os.makedirs() will use the given mode
without modification, you have to execute os.umask(0)
beforehand.
So this bug is probably invalid if you forgot to set your
umask accordingly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106572&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 16:04
Message generated for change (Comment added) made by calvin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
Comment By: Wummel (calvin)
Date: 2005-01-24 13:51
Message:
Logged In: YES
user_id=9205
This should probably also be added to rsplit()?
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-01-24 08:15
Message:
Logged In: YES
user_id=593130
To me, the removal of whitespace at the ends (stripping) is
consistent with the removal (or collapsing) of extra
whitespace in between so that .split() does not return empty
words anywhere. Consider:
>>> ',1,,2,'.split(',')
['', '1', '', '2', '']
If ' 1 2 '.split() were to return null strings at the beginning
and end of the list, then to be consistent, it should also put
one in the middle. One can get this by being explicit (mixed
WS can be handled by translation):
>>> ' 1 2 '.split(' ')
['', '1', '', '2', '']
Having said this, I also agree that the extra words proposed
by jj are helpful.
BUG?? In 2.2, splitting an empty or whitespace only string
produces an empty list [], not a list with a null word [''].
>>> ''.split()
[]
>>> ' '.split()
[]
which is what I see as consistent with the rest of the no-null-
word behavior. Has this changed since? (Yes, must
upgrade.) I could find no indication of such change in either
the tracker or CVS.
--
Comment By: YoHell (yohell)
Date: 2005-01-20 15:59
Message:
Logged In: YES
user_id=1008220
Brilliant, guys!
Thanks again for a superb scripting language, and with
documentation to match!
Take care!
/Joel Hedlund
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 15:50
Message:
Logged In: YES
user_id=80475
The prosposed wording is fine.
If there are no objections or concerns, I'll apply it soon.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2005-01-20 15:28
Message:
Logged In: YES
user_id=764593
Replacing the quoted line:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. First whitespace (spaces, tabs,
newlines, returns, and formfeeds) is stripped from both
ends. Then words are separated by arbitrary length
strings of whitespace characters . Consecutive whitespace
delimiters are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty (or whitespace-
only) string returns "['']".
"""
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 15:04
Message:
Logged In: YES
user_id=80475
What new wording do you propose to be added?
--
Comment By: YoHell (yohell)
Date: 2005-01-20 11:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
[ python-Bugs-1108490 ] broken link in tkinter docs
Bugs item #1108490, was opened at 2005-01-24 09:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: broken link in tkinter docs Initial Comment: "Compound" link on http://www.python.org/doc/current/lib/node721.html is broken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1108490&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-904498 ] threading docs, start error should be specified
Bugs item #904498, was opened at 2004-02-25 12:00 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: threading docs, start error should be specified Initial Comment: The docs say it is an error to start a threading thread more than once, but they do not specify exactly what exception will be raised. Apparently it is always AssertionError (though an expert should verify this). It would be very helpful to document the exception because there is no other documented way to tell if a threading thread has been started than to try to start it. I posted to the dev group on 2003-02-24 about this and Aahz asked me to file a doc bug. So here it is. I suggest the info go in the Thread object docs, in the documentation for "start". -- >Comment By: Russell Owen (reowen) Date: 2005-01-24 11:47 Message: Logged In: YES user_id=431773 There is still the problem that the threading module presents no reasonable way to tell if a thread is safe to start (i.e. whether or not it has already been started). A standard documented exception is one way to handle this (AssertionError is clearly not the best choice). A method or attribute would be even better, but would require a change in interface. Right now one has to keep a separate state flag, which is risky. -- Comment By: Alan Green (alanvgreen) Date: 2005-01-22 02:30 Message: Logged In: YES user_id=1174944 The actual wording in the documentation is: "This must be called at most once per thread object." To me this implies that the effect of calling start() twice is not defined. There is an assert statement in the implementation of Thread.start(), but - like all assert statements - its behaviour is dependent upon the value of the builtin __debug__ variable. Looking through the rest of the threading module, the documentation could be tightened up, particularly with respect to which behaviours are and aren't defined. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-968430 ] error flattening complex smime signed message
Bugs item #968430, was opened at 2004-06-07 16:34 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ludovico Magnocavallo (ludo) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: error flattening complex smime signed message Initial Comment: Python 2.3.3 [GCC 3.2.2] on linux2 email version 2.5.5 Complex SMIME signed messages parsed and flattened again do not pass SMIME verification. I have noticed this with messages that have as message/rfc822 attachment another SMIME signed message. A diff between an "original" SMIME signed messaged passign openssl smime -verify verification and the same message parsed (message_from_file) and flattened (as_string(False)) by the email library: diff -bB bugmsg_signed.eml bugmsg_signed_parsed.eml 2c2,3 < Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" --- > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="381546B4549948B9F93D885A82884C49" The email-parsed message splits the signature header into two lines, thus rendering the message non-valid. Attached to this bug a .zip archive with: - msg #1: the non-signed message (with a signed message as attachment) - msg #2: message #1 signed by openssl - msg #3: message #2 parsed and flattened as described above - the CA certificate file used for smime verification openssl command used to verify #2 and #3: openssl smime -verify -in bugmsg_signed.eml -CAfile cacert.pem openssl smime -verify -in bugmsg_signed_parsed.eml -CAfile cacert.pem -- Comment By: Bas Wijnen (shevek) Date: 2005-01-24 06:43 Message: Logged In: YES user_id=42389 I would like to add that I think this bug is quite important, as mailman uses python. This means that many mailing lists invalidate signatures when signed e-mails with attachments are sent through them. As attachments are often code patches, it is quite important that the signatures are working correctly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
