From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Wed, 25 Sep 2013 21:45:38 +0200
Subject: IRC.

---
 open_issues/exec.mdwn | 49 ++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 48 insertions(+), 1 deletion(-)

(limited to 'open_issues/exec.mdwn')

diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
index ff3fccf5..fe70123d 100644
--- a/open_issues/exec.mdwn
+++ b/open_issues/exec.mdwn
@@ -10,7 +10,10 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
-IRC, unknown channel, unknown date.
+[[!toc]]
+
+
+# IRC, unknown channel, unknown date.
 
     <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang
     <youpi> support in exec* I meant
@@ -18,6 +21,50 @@ IRC, unknown channel, unknown date.
     <youpi> now a funny bug: if I disable gzip/bzip2 support from exec
     <youpi> trying to run a zero-byte file hangs
 
+
+## 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:
+      http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html
+    <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.
-- 
cgit v1.2.3