Pd-dev October 2007

pd-dev@lists.iem.at

30 participants
183 discussions

[ pure-data-Patches-1822943 ] hexloader code security issue
by SourceForge.net 30 Oct '07

30 Oct '07

Patches item #1822943, was opened at 2007-10-30 11:27 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_… 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: puredata Group: bugfix Status: Open Resolution: None Priority: 9 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: hexloader code security issue Initial Comment: the hexmunge code in s_loader.c exposes a security hole: s_loader:127 reads: memmove(symname+6, symname, strlen(symname+1)); but really it should read: memmove(symname+6, symname, strlen(symname)+1); the code tries to copy the \0 character, but fails to do so (because the strlen(+1) returns to few bytes to be copied), which results in garbage in the symname after the memmove. since this bug is a real security hole, i give it a high priority ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-30 11:52 Message: Logged In: NO if this is a real security hole, then how would anyone exploit it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_…

1 0

[ pure-data-Patches-1822943 ] hexloader code security issue
by SourceForge.net 30 Oct '07

30 Oct '07

Patches item #1822943, was opened at 2007-10-30 19:27 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_… 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: puredata >Group: bugfix Status: Open Resolution: None Priority: 9 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) >Summary: hexloader code security issue Initial Comment: the hexmunge code in s_loader.c exposes a security hole: s_loader:127 reads: memmove(symname+6, symname, strlen(symname+1)); but really it should read: memmove(symname+6, symname, strlen(symname)+1); the code tries to copy the \0 character, but fails to do so (because the strlen(+1) returns to few bytes to be copied), which results in garbage in the symname after the memmove. since this bug is a real security hole, i give it a high priority ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_…

1 0

[ pure-data-Patches-1822943 ] hexloader code broken!
by SourceForge.net 30 Oct '07

30 Oct '07

Patches item #1822943, was opened at 2007-10-30 19:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_… 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: puredata Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: hexloader code broken! Initial Comment: the hexmunge code in s_loader.c exposes a security hole: s_loader:127 reads: memmove(symname+6, symname, strlen(symname+1)); but really it should read: memmove(symname+6, symname, strlen(symname)+1); the code tries to copy the \0 character, but fails to do so (because the strlen(+1) returns to few bytes to be copied), which results in garbage in the symname after the memmove. since this bug is a real security hole, i give it a high priority ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822943&group_…

1 0

pdp's mmx support
by Hans-Christoph Steiner 30 Oct '07

30 Oct '07

I just saw that PDP has some MMX assembly (old school ;). Do you think it would be worth turning on, even tho MMX seems to be deprecated? The code is in externals/pdp/system/mmx Auto-vectorization only got about 5 or 6 loops. .hc ------------------------------------------------------------------------ ---- I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

3 8

editmodefn
by Hans-Christoph Steiner 30 Oct '07

30 Oct '07

I was thinking that that it would be quite handy to have an addition callback in the GUI API. Basically, it would be a function that is called whenever editmode changes. This would allow objects to do things like only draw their inlets and outlets when edit mode is on, or be able to change the background color in edit mode. Any thoughts, comments, flames, etc? .hc ------------------------------------------------------------------------ ---- There is no way to peace, peace is the way. -A.J. Muste

1 0

pdtk_canvas_click and focus
by Hans-Christoph Steiner 29 Oct '07

29 Oct '07

Anyone know why the focus statement below only applies to GNU/Linux? This would make life much easier on Mac OS X when writing GUIs that handle focus: proc pdtk_canvas_click {name x y b f} { global pd_nt if {$pd_nt == 0} {focus $name} pd [canvastosym $name] mouse [$name canvasx $x] [$name canvasy $y] $b $f \; } .hc ------------------------------------------------------------------------ ---- I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

2 1

iemgui crash when compiling against 0.41
by Hans-Christoph Steiner 29 Oct '07

29 Oct '07

I noticed that compiling footils/knob/knob.c and moonlib/mknob.c against Pd-0.41-test06 (HEAD of MAIN), I get a crash when using that object binary with Pd-0.40.3-extended-20071028.app and Pd-0.39.3- extended.app on Mac OS X. Is there some change in 0.41 that might cause this? Here's the stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000000 0x0079004b in mknob_check_minmax () (gdb) bt #0 0x0079004b in mknob_check_minmax () #1 0x00039e93 in obj_list (x=0x12, s=0x6a4130, argc=18, argv=0x603d10) at m_obj.c:227 #2 0x00039f21 in obj_list (x=0x0, s=0x6a4130, argc=18, argv=0x0) at m_obj.c:237 #3 0x00039c40 in inlet_anything (x=0x190980, s=0x6a4130, argc=18, argv=0x8a470) at m_obj.c:126 #4 0x0003d487 in binbuf_convert (oldb=0x12, maxtopd=-1073765512) at m_binbuf.c:1007 #5 0x0000945f in canvas_toggle (gl=0x0, s=0x6a81b0, argc=566208, argv=0x43970000) at g_text.c:188 #6 0x00009619 in canvas_numbox (gl=0x6a7a80, s=0x603f20, argc=21, argv=0x8a3c0) at g_text.c:234 #7 0x00039bed in inlet_list (x=0x6a7a80, s=0x9c1, argc=21, argv=0x8a3c0) at m_obj.c:121 #8 0x0003d487 in binbuf_convert (oldb=0x12, maxtopd=13420) at m_binbuf.c:1007 #9 0x0004036c in m_scheduler () at m_sched.c:400 #10 0x000403f3 in m_scheduler () at m_sched.c:452 #11 0x00039d06 in pointerinlet_pointer (x=0x190b10, gp=0x60d2d0) at m_obj.c:153 #12 0x0003d487 in binbuf_convert (oldb=0x12, maxtopd=0) at m_binbuf.c: 1007 #13 0x00044548 in sys_loadpreferences () at s_file.c:397 #14 0x0004361a in sys_startgui (guidir=0x0) at s_inter.c:874 #15 0x0004367f in sys_startgui (guidir=0x1388 "") at s_inter.c:879 #16 0x00041501 in sys_argparse (argc=6349136, argv=0xbfffef04) at s_main.c:674 #17 0x00043407 in socketreceiver_read (x=0x3, fd=-1073745796) at s_inter.c:430 #18 0x000022d2 in mknob_check_minmax () Cannot access memory at address 0xf9c .hc ------------------------------------------------------------------------ ---- The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

1 0

[ pure-data-Bugs-1818219 ] namespace prefix not included in save functions
by SourceForge.net 29 Oct '07

29 Oct '07

Bugs item #1818219, was opened at 2007-10-22 18:50 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&group_… 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: puredata >Group: v0.40.2 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: stffn (stffn) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: namespace prefix not included in save functions Initial Comment: 1. Open the attahced patch in Pd-extended. 2. Notice the both [list-abs/wrandom] and [unauthorized/grid] gets created. 3. Save the patch whit out making any chages. 4. Close the patch. 5. CLose Pd-extended. 6. Open the patch again. 7. See that the grid objects doesn't get created and (since) the the prefix has been removed. This happens in Pd-extended-0.39.3 mac intel. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-29 14:59 Message: Logged In: YES user_id=27104 Originator: NO Thru this thread, we figured out the fix: http://lists.puredata.info/pipermail/pd-dev/2007-10/009797.html Here's how to get the whole classname in the save function: static void entry_save(t_gobj *z, t_binbuf *b) { t_entry *x = (t_entry *)z; t_symbol *classname = atom_getsymbol(binbuf_getvec(x->x_obj.te_binbuf)), binbuf_addv(b, "ssiisiiss", gensym("#X"),gensym("obj"), x->x_obj.te_xpix, x->x_obj.te_ypix, classname, x->x_width, x->x_height, x->x_bgcolour, x->x_fgcolour); binbuf_addv(b, ";"); } I added this fix to these objects: bbogart/popup/popup.c ffext/tracker/tracker.c footils/knob/knob.c ggee/gui/button.c ggee/gui/gcanvas.c ggee/gui/image.c ggee/gui/slider.c ggee/gui/sliderh.c ggee/gui/ticker.c ggee/gui/toddle.c ggee/gui/w_envgen.h hcs/cursor.c miXed/cyclone/hammer/Table.c miXed/cyclone/hammer/comment.c miXed/cyclone/hammer/funbuff.c miXed/cyclone/sickle/Scope.c miXed/toxy/widget.c moonlib/gamme.c moonlib/image.c moonlib/mknob.c pdvjtools/colorgrid/colorgrid.c pdvjtools/imagegrid/imagegrid.c pdvjtools/videogrid/videogrid.c pidip/modules/pdp_colorgrid.c unauthorized/audience~/audience~.c unauthorized/cooled~/cooled~.c unauthorized/exciter/exciter.c unauthorized/filterbank~/filterbank~.c unauthorized/grid/grid.c unauthorized/pianoroll/pianoroll.c unauthorized/probalizer/probalizer.c unauthorized/scratcher~/scratcher~.c unauthorized/scrolllist/scrolllist.c unauthorized/sonogram~/sonogram~-joge.c unauthorized/sonogram~/sonogram~-yves.c unauthorized/sonogram~/sonogram~.c That leaves the code in externals/iem, pd/src/, and some of the more complex objects in externals/miXed. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-26 23:32 Message: Logged In: NO yeah, because of the m_imp.h inclusion, this is a problem. it could be solved by adding a function to m_pd.h that returns the class name as a symbol or C string, whichever is more convenient. i think that it's much easier than changing the interface. otherwise, you could make another class_setsavefn that would register the fact that you want the 5 atoms "#X" "obj" x1 y1 classname to be written before the savefn is called. The original has to be kept both because of backward-compatibility and because it's possible to make externals that have a subpatch-like behaviour (though no-one has tried doing that yet!) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-26 12:12 Message: Logged In: YES user_id=27104 Originator: NO If every patch is going to add (*(t_pd *)x)->c_name->s_name to the savefn, then it seems to me that there should be a mechanism in Pd itself to do this automatically. Then the interface might need to be different. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-10-25 21:14 Message: Logged In: NO hans, it's not the meaning of t_savefn itself that has to be changed: it's just every use t_savefn, that is, every blah_savefn function that gets registered, if they aren't already using (*(t_pd *)x)->c_name->s_name. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-25 13:24 Message: Logged In: YES user_id=27104 Originator: NO This sounds like an excellent idea! I think that this improved savefn will probably need to be distinct from the current savefn stuff, since it probably wouldn't be compatible. But if it could be the same mechanism, that would be even better. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2007-10-24 05:42 Message: Logged In: YES user_id=564396 Originator: NO i changed the category, since it is a problem with pd (though it affects externals) i changed the name, because it is not gui-specific: every object that defines a savefn() is affected by this (usually only gui-classes do this because they are the classes where you cannot directly edit the arguments (being hidden) and which might offer a properties window to change these arguments) however: i think it is a great feature that an object is able to change it's own name (really). nevertheless, an object should also be able to _query_ it's own name. this is usually not a big problem because the object assumes that it knows how it is called (the name the dev gave it). when using namespaces this is not the case any more. basically: the object would need a way to easily query it's own name (i am sure it is somehow possible via weird t_canvas/t_class/t_obj/t_pd/... pointer magic which is so complicated i will have to re-read to source code) the savefn() should provide a way to set object-name and arguments separately, the object-name should default to the actual name (not the canonical one) if not set otherwise. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-23 20:50 Message: Logged In: YES user_id=27104 Originator: NO I found the root of the problem, if the GUI object has a savefn, then that savefn needs to include the whole classname, including the namespace prefix. I think stffn was right, it does apply to all GUIs. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-23 17:09 Message: Logged In: YES user_id=27104 Originator: NO This doesn't happen to all GUI objects, just some. I think [grid] is one, but many others work fine with the prefixes. ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-10-23 03:44 Message: Logged In: YES user_id=1658640 Originator: YES True, this also happens in Pd version 0.40-2. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-22 19:40 Message: Logged In: YES user_id=27104 Originator: NO This happens on Pd-0.40.3-extended-20071021 on Mac OS X also. Has anyone tested this on other GOPs? I know pddp/pddplink works fine. Also cyclone/Scope~ also works. I think this might be an issue with the objects themselves. ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-10-22 18:52 Message: Logged In: YES user_id=1658640 Originator: YES I forgot to mention that it happens to quite many if not all the GUI objects. At least those in CVSROOT/doc/pddp/about/GUIs-about.pd. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1818219&group_…

1 0

[ pure-data-Patches-1822220 ] include PDP MMX support, and turn on compiler optimizatons
by SourceForge.net 29 Oct '07

29 Oct '07

Patches item #1822220, was opened at 2007-10-29 13:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822220&group_… 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: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: include PDP MMX support, and turn on compiler optimizatons Initial Comment: There is a whole suite of functions written MMX assembler for MMX. This should be enabled in the x86 PDP builds in Pd-extended. Also, it would be worthwhile to try the gcc 4.1 compiler optimizations ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822220&group_…

1 0

[ pure-data-Patches-1822010 ] hardcoded sample-type in soundfile-IO
by SourceForge.net 29 Oct '07

29 Oct '07

Patches item #1822010, was opened at 2007-10-29 11:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822010&group_… 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: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: hardcoded sample-type in soundfile-IO Initial Comment: the current implementation in d_soundfile.c assumes that both t_sample and t_float are "float". this is not necessarily true. additionally it assumes that typeof(t_sample) and typeof(t_float) are identically. this is not necessarily true. based on the assumption that (number)arrays are of type t_float and signals are of type t_sample, the attached patch provides 2 extra functions for xferin/xferout that use different types for reading/writing soundfiles. basically it provides: soundfile_xferin_sample() (reading soundfile to signal) soundfile_xferin_float() (reading soundfile to table) soundfile_xferout_sample() (writing soundfile from signal) soundfile_xferout_float() (writing soundfile from table) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1822010&group_…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev October 2007