[www] 01/02: import some old news posts

[gnunet]

This is an automated email from the git hooks/post-receive script.

martin-schanzenbach pushed a commit to branch master
in repository www.

commit c3bf63a41d68549b769d465205050c1a271dfb67
Author: Martin Schanzenbach <mschanzenbach@posteo.de>
AuthorDate: Wed Mar 10 16:20:54 2021 +0100

    import some old news posts
---
 news/2011-11-24-archived-vfork.html.j2       | 62 ++++++++++++++++++++++++++++
 news/2013-12-28-archived-typos-pkeys.html.j2 | 16 +++++++
 news/oldnews-2011.html.j2                    |  1 +
 news/oldnews-2013.html.j2                    |  1 +
 4 files changed, 80 insertions(+)

diff --git a/news/2011-11-24-archived-vfork.html.j2 
b/news/2011-11-24-archived-vfork.html.j2
new file mode 100644
index 0000000..61249c3
--- /dev/null
+++ b/news/2011-11-24-archived-vfork.html.j2
@@ -0,0 +1,62 @@
+{% extends "common/news.j2" %}
+{% block body_content %}
+  <h1>vfork and the signal race</h1>
+<p>
+  <b>This is an imported news item from the old Drupal GNUnet homepage.</b>
+</p>
+<p>
+Many articles uniformly claim that using vfork should be
+<a 
href="https://web.archive.org/web/20150924082249/http://tldp.org/HOWTO/Secure-Programs-HOWTO/avoid-vfork.html";>avoided</a>
+and that the only difference between vfork and fork is (or used-to-be)
+<a 
href="https://web.archive.org/web/20150924082249/http://www.unixguide.net/unix/programming/1.1.2.shtml";>performance</a>
+and that thus vfork is
+<a 
href="https://web.archive.org/web/20150924082249/http://stackoverflow.com/questions/4856255/the-difference-between-fork-vfork-exec-and-clone";>obsolete</a>.
+Here, I wanted to document a technical case where vfork is actually required 
and where using fork instead of vfork (or operating system implementors 
implementing vfork as an alias for fork) causes a hard-to-find data race.
+</p>
+<p>
+GNUnet uses a hypervisor process (gnunet-service-arm) to control the peer's 
service processes. Services are started (vfork+exec) on-demand. The hypervisor 
is also responsible for stopping the services and sends a SIGTERM signal to the 
services to stop them. SIGTERM must be used to allow the services to shutdown 
gracefully. Naturally, after shutting down a service with a signal, the 
hypervisor waits for SIGCHILD and then cleans up with waitpid. Once all 
services processes have completed,  [...]
+</p>
+<p>
+The reason why we must use vfork is the following. After the hypervisor has 
started the service, it might be asked to stop the service at any time. We've 
actually managed (by scripting it) to reliably trigger a case where the 
hypervisor would start a service (fork) and then receive a request to terminate 
the service and issues the SIGTERM signal to the child before the child process 
had a chance to call exec. As a result, the SIGTERM would go to the (existing) 
handler of the hypervisor's [...]
+</p>
+<p>
+If exec wins, the signal either kills the process hard during the service 
startup phase, which is fine, or the service process might handle it normally 
and terminate --- also fine).
+</p>
+<p>
+If kill wins the race, the signal would be lost and the hypervisor would wait 
'forever' for the child to terminate.
+</p>
+<p>
+The solution with vfork is elegant and simple: by blocking the parent, vexec 
guarantees that the parent's signal handler is no longer active (and replaced 
by default handlers or the child's custom handlers) by the time the parent is 
able to issue a 'kill'.
+</p>
+<p>
+In conclusion, with parents that issue 'kill' on child processes, the use of 
vfork can make an important semantic difference and not only (possibly) offer 
performance advantages. The situation above cannot be easily fixed by other 
means and thus vfork is an important POSIX call that should be supported 
properly by all quality implementations. A possible hack to work around a lack 
of vfork would be to create a pipe in the parent, set it to close-on-exec, fork 
the child, close the write en [...]
+</p>
+<p>
+Currently, gnunet-service-arm can hang indefinitely on systems that do not 
provide a correct implementation of vfork (however, in practice normal users 
should never encounter this).
+</p>
+<p>
+<b>better suggestion from Thomas Bushnell</b>
+<br>
+I just got an alternative suggestion to using either a pipe and vfork from 
Thomas Bushnell, which I like and will use:
+
+"The hypervisor at start creates a global variable hypervisor_pid, initialized 
from getpid().
+
+The signal handler in the hypervisor then does this:
+<br>
+<code class="block">
+if getpid() == hypervisor_pid<br>
+  kill_all_children_and_exit();<br>
+else<br>
+  exit();<br>
+</code>
+
+In this way, if the child is between fork and exec when the parent gets its 
kill, and then it tries to kill the child, and the kill happens before the 
child execs (the problematic case you describe), then the child simply enters 
the hypervisor's signal handler, notices that it's not the hypervisor, and 
exits.
+<br>
+Thomas"
+<br>
+Thanks for the suggestion!
+</p>
+<p>
+Thomas's suggestion is all fine and well, except that it doesn't work on OS X. 
As the attached simple program "killing-child-kills-parent.c" demonstrates, OS 
X manages to sometimes either deliver the signal to the wrong process (?) or 
not update getpid() between fork+exec or is otherwise generally broken. The 
program simply installs a signal handler in the parent with the guard suggested 
by Thomas, then forks + exec's "sleep" and then immediately kills the child. So 
we expect the signal  [...]
+</p>
+{% endblock body_content %}
diff --git a/news/2013-12-28-archived-typos-pkeys.html.j2 
b/news/2013-12-28-archived-typos-pkeys.html.j2
new file mode 100644
index 0000000..a541ef9
--- /dev/null
+++ b/news/2013-12-28-archived-typos-pkeys.html.j2
@@ -0,0 +1,16 @@
+{% extends "common/news.j2" %}
+{% block body_content %}
+  <h1>Typo-Protected Public Keys</h1>
+<p>
+  <b>This is an imported news item from the old Drupal GNUnet homepage.</b>
+</p>
+<p>
+When users type in public keys (such as the 53-characters of a GNS zone), they 
might make typos. The usual way to fix typos is to add a checksum, further 
increasing the length of the sequence that has to be typed in.
+<br>
+We can fix this by including the checksum of the public key in the public key 
itself, simply by trying new private keys until the corresponding public key 
happens to have a checksum (over the other bits) in the bits designated for the 
checksum. If a checksum is 16 bits, we would only need to try 216 keys. The 
basic idea of brute-forcing keys to match a particular pattern <a 
href="https://web.archive.org/web/20141008173738/https://bitcointalk.org/index.php?topic=84569.0";>was
 proposed befo [...]
+</p>
+<p>
+<b>Acknowledgements</b><br/>
+The idea popped up in a discussion on the need for short public keys for GNS 
with Dan Bernstein and Tanja Lange at 30c3.
+</p>
+{% endblock body_content %}
diff --git a/news/oldnews-2011.html.j2 b/news/oldnews-2011.html.j2
new file mode 120000
index 0000000..ef5fcbe
--- /dev/null
+++ b/news/oldnews-2011.html.j2
@@ -0,0 +1 @@
+oldnews-2018.html.j2
\ No newline at end of file
diff --git a/news/oldnews-2013.html.j2 b/news/oldnews-2013.html.j2
new file mode 120000
index 0000000..ef5fcbe
--- /dev/null
+++ b/news/oldnews-2013.html.j2
@@ -0,0 +1 @@
+oldnews-2018.html.j2
\ No newline at end of file

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.