[ 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 gagern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=968430&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No 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: Martin von Gagern (gagern) Date: 2007-02-28 13:07 Message: Logged In: YES user_id=733620 Originator: NO At least for the header wrapping issue, adding a new handler to the default Generator implementation should provide an easy solution. I just created patch 968430 http://tinyurl.com/2chhz6 for this. >From mailman bug report 815297 http://tinyurl.com/2a8dta I understand that there is a fix in mailman for this issue as well, but I believe this patch would be a fix any python program would want, not just mailman. There remains an issue about leading space in headers, mentioned in that mailman problem report as well. The cause is an lstrip call in FeedParser. However removing that would probably break a lot of existing programs. And modifying all methods accessing the headers to remove or add leading space would be somewhat ugly. Right now I'm trying to figure out how to save the unmodified body for every multipart/signed message, so that it can be stored with the message and used without any modifications during generation. -- Comment By: Harald Tveit Alvestrand (hta) Date: 2005-09-08 08:16 Message: Logged In: YES user_id=12193 Adding my voice that the bug is important. This is now the chief culprit in breaking signed messages in my usage of signed email on the net; that "signtures are so often broken" is one argument people often use against using signed email. -- Comment By: Bas Wijnen (shevek) Date: 2005-01-25 10:37 Message: Logged In: YES user_id=42389 In case it is any help, I tried to find the problem in the source. I don't speak python, so I can't fix anything, but I do speak C, so it's quite readable. :-) It seems to me that the problem is in Lib/email/Message.py, in particular in _parseparam and _get_params_preserve. Both these functions call strip() on the object several times (which seems a bit overdone anyway ;-) ), which I presume removes all whitespace around them. I think the whitespace should somehow be saved (not stripping will probably break many programs, so that's not a good idea), so it can be used again when the header is written. set_param should of course also fill this value, so new params get a defined separation (although the empty string is quite acceptable). How this should be implemented I gladly leave to someone who actually speaks Python. :-) -- 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
[ python-Bugs-1671137 ] slice obj with no start index is 0 instead of None sometimes
Bugs item #1671137, was opened at 2007-02-28 11:58
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=1671137&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes
Initial Comment:
Slice objects returned by the slice ":42" return different slice objects
depending on whether the entire slice operation is simple or extended. This bit
of code explains it best:
class SliceBug:
def __getitem__(self, sliceArg):
print sliceArg
s = SliceBug()
s[:42]
s[:42,]
s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)
Note that this bug only occurs on classes that do no inherit from object ("old
style" classes). If you change the class to make it inherit from "object" both
slices have None as their start index. Oddly enough in Python 3000 it still
only happens on "old style" classes even though supposedly they are the same as
new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and
2.2. Seems to be a long standing bug/feature.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671137 ] slice obj with no start index is 0 instead of None sometimes
Bugs item #1671137, was opened at 2007-02-28 11:58
Message generated for change (Comment added) made by jyzude
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Verdone (jyzude)
Assigned to: Nobody/Anonymous (nobody)
Summary: slice obj with no start index is 0 instead of None sometimes
Initial Comment:
Slice objects returned by the slice ":42" return different slice objects
depending on whether the entire slice operation is simple or extended. This bit
of code explains it best:
class SliceBug:
def __getitem__(self, sliceArg):
print sliceArg
s = SliceBug()
s[:42]
s[:42,]
s[:42] produces slice(0, 42, None)
s[:42,] produces (slice(None, 42, None),)
Note that this bug only occurs on classes that do no inherit from object ("old
style" classes). If you change the class to make it inherit from "object" both
slices have None as their start index. Oddly enough in Python 3000 it still
only happens on "old style" classes even though supposedly they are the same as
new style classes. I have also reproduced the bug in Python 2.6, 2.4, 2.3, and
2.2. Seems to be a long standing bug/feature.
--
>Comment By: Mike Verdone (jyzude)
Date: 2007-02-28 12:04
Message:
Logged In: YES
user_id=584997
Originator: YES
Correction! This is fixed in Python 3000. I just have too many windows
open and too many branches checked out.
File Added: slicebug.py
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671137&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1649098 ] non-standard: array[0]
Bugs item #1649098, was opened at 2007-01-31 19:25
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Abt (jabt)
Assigned to: Thomas Heller (theller)
Summary: non-standard: array[0]
Initial Comment:
in Modules/_ctypes/ctypes.h:
typedef struct {
[..]
ffi_type *atypes[0];
} ffi_info;
AFAIK, arrays must be of size > 0.
_Most_ compilers accepts this, but not all
(especially my HP-UX compiler).
Please change *atypes[0] to *atypes[1]!
Bye,
Johannes
--
>Comment By: Thomas Heller (theller)
Date: 2007-02-28 21:43
Message:
Logged In: YES
user_id=11105
Originator: NO
I can, and probably will, change this in Modules/_ctypes/ctypes.h.
However, I'm afraid it will not help the OP too much because it seems he
cannot sucessfully compile the libffi sources with this HP-UX compiler
anyway because of at least *some* other problems.
I have the impression that libffi is GCC-specific, and unless someone
provides a complete patch for the HP-UX (or other) compilers it will
probably stay this way.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-02-25 23:24
Message:
Logged In: YES
user_id=33168
Originator: NO
Thomas, could you take a look?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1649098&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669498 ] 2.4.4 Logging LogRecord attributes broken
Bugs item #1669498, was opened at 2007-02-26 22:18
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Murray (murrayg)
>Assigned to: Vinay Sajip (vsajip)
Summary: 2.4.4 Logging LogRecord attributes broken
Initial Comment:
The following module gives different results under 2.4.3 and 2.4.4
(running on Kubuntu, Dapper and Edgy releases, resp.)
#!/usr/bin/env python
import logging
logger = logging.getLogger("MyLogger")
logger.setLevel(logging.DEBUG)
handler = logging.StreamHandler()
format = "%(levelname)-8s %(module)s %(lineno)d %(message)s"
handler.setFormatter(logging.Formatter(format))
logger.addHandler(handler)
logger.info("Yo")
On 2.4.3 I get
INFO tmplogger 11 Yo
On 2.4.4 I get
INFO __init__ 1072 Yo
The versions are
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
and
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
[GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)] on linux2
--
>Comment By: Vinay Sajip (vsajip)
Date: 2007-02-28 21:15
Message:
Logged In: YES
user_id=308438
Originator: NO
Can you please delete all logging .pyc files before running the test
script? The problem appears to be caused by the __file__ value stored
inside a .pyc being different (possibly due to symlink changes) from the
source file it was originally compiled from.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669498&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Bugs item #1671411, was opened at 2007-03-01 11:27 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=1671411&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC Initial Comment: Hi, Python-2.5 code fails with "MemoryError". This is happening only on one system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed, non-failing system has 8 GB. 1) spark 9GB phys mem(Python is working fine) 2) stalker 12GB phys mem (that has problem with python 2.5 ) please assist me in this. Thanks in advance Shashi -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1671411 ] python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Bugs item #1671411, was opened at 2007-03-01 05:27
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Performance
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shashi (shashikala)
Assigned to: Nobody/Anonymous (nobody)
Summary: python code fails with "MemoryError" on HP-UX 11.11 PA_RISC
Initial Comment:
Hi,
Python-2.5 code fails with "MemoryError". This is happening only on one
system, PA-RISC running HP-UX 11.11.Failing system has 12 GB of RAM installed,
non-failing system has 8 GB.
1) spark 9GB phys mem(Python is working fine)
2) stalker 12GB phys mem (that has problem with python 2.5 )
please assist me in this.
Thanks in advance
Shashi
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-03-01 07:38
Message:
Logged In: YES
user_id=21627
Originator: NO
This tracker is not about assistance. If at all, we need you to assist
us.
Can you please report more details, like stack traces, causes of the
crash, patches? If not, I think there is little we can do about this report
("it crashes" is pretty unspecific).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1671411&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1669743 ] Python needs a way to detect implementation
Bugs item #1669743, was opened at 2007-02-27 08:32 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kay Hayen (kayhayen2) Assigned to: Nobody/Anonymous (nobody) Summary: Python needs a way to detect implementation Initial Comment: Hello, I am currently writing an application that will run under both CPython and PyPy. In this I encountered the need to discover the implementation of the current interpreter. For example, with PyPy the use of StringIO may offer benefits due to the possibility of more complete analysis of data flows during compilation or JIT execution. I want to take advantage of this. (Granted, currently pypy will run on top of CPython most of the time, so it's not the real solution to my problem until PyPy-c is at comparable performance). This is only example, a lot of different performance behaviors exist, that at times, will make sense to be abstracted. I have checked module sys of both implementations (plus Jython) and found in CPython only the property "subversion", which contains a tuple with CPython being the first element. My suspect is though that this is related to the detail of using svn in CPython development, and as such, would not be a good standard. So, what I believe with more and more Python versions existing (e.g. IronPython), it is needed to have sys.implementation that puts sys.version into context. My proposal is that CPython leads the effort to aid this, and the other Python variants can then adopt the standard property. Thank you in advance, Kay Hayen -- >Comment By: Martin v. Löwis (loewis) Date: 2007-03-01 07:40 Message: Logged In: YES user_id=21627 Originator: NO Please take a look at sys.subversion. This is fixed in Python 2.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1669743&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
