path: root/service_solahart_jakarta_selatan__082122541663/exec.mdwn
diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/exec.mdwn')
1 files changed, 84 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/exec.mdwn b/service_solahart_jakarta_selatan__082122541663/exec.mdwn
new file mode 100644
index 00000000..05deaa7a
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/exec.mdwn
@@ -0,0 +1,84 @@
+[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]]
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+[[!tag open_issue_hurd]]
+# IRC, unknown channel, unknown date.
+ <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang
+ <youpi> support in exec* I meant
+ <youpi> now a funny bug: if I disable gzip/bzip2 support from exec
+ <youpi> trying to run a zero-byte file hangs
+Justus: This doesn't seem to be an issue anymore (2013-09-08):
+ % touch empty
+ % chmod +x empty
+ % ./empty
+ zsh: exec format error: ./empty
+ % bash
+ $ ./empty
+ $
+Also I've never encountered a problem with apt.
+## IRC, freenode, #hurd, 2013-08-01
+ <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code
+ all over it and it looks like that isn't even used anymore
+ <teythoon> that's too bad actually, I figured out how to get the values
+ from BFD, not so for the other elf parser that is used instead
+## IRC, freenode, #hurd, 2013-08-05
+ <teythoon> btw, there is a Debian bug concerning zipped executables. now
+ I'm not sure if I understood the problem, but gziped and bzip2ed
+ executables work for me
+ <teythoon> (not that I'm a big fan of that particular feature)
+ <youpi> iirc these somehow got fixed yes
+ <youpi> something like a previous out of bound access
+ <teythoon> the exec server contains lot's of code that is unused and
+ probably bit rot (#ifdef BFD) or otherwise ignored (#if 0)
+ <youpi> yes :/
+ <teythoon> and there's gunzipping and bunzip2ing, which we probably don't
+ want anyway
+ <pinotree> why not?
+ <teythoon> we should strip all that from exec and start adding features
+ <teythoon> pinotree: b/c it's slow and the gain is questionable
+ <teythoon> it breaks mmapping the code in
+ <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an
+ essential server
+ <teythoon> and I wonder if the unzipping is done securely, e. g. if it's
+ not possible to crash exec with an maliciously compressed executable
+## IRC, freenode, #hurd, 2013-09-12
+ <rekado> The zip code in hurd/exec/ looks really complicated; does it
+ really just unpack zipped files in memory (which could be replaced by
+ library calls) or is there something else going on?
+ <braunr> rekado:
+ <rekado> braunr: interesting. Thanks.
+ <rekado> Does this mean that the "small hack entry" on the contributing
+ page to use libz and libbz2 in exec is no longer valid?
+ <braunr> probably
+May want to have a look at using BFD / libiberty/simpleobject.
+Justus: The BFD code has been removed from the exec server.