[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH 3/5] * open_issues/exec.mdwn: delete file.

From: address@hidden
Subject: [PATCH 3/5] * open_issues/exec.mdwn: delete file.
Date: Mon, 15 May 2023 11:34:55 -0400

 open_issues/exec.mdwn | 84 -------------------------------------------
 1 file changed, 84 deletions(-)
 delete mode 100644 open_issues/exec.mdwn

diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
deleted file mode 100644
index 05deaa7a..00000000
--- a/open_issues/exec.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!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:
-      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.
-Justus: The BFD code has been removed from the exec server.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]