[www] branch master updated (3ea16c9 -> eb0a5c7)

[gnunet]

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

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

    from 3ea16c9  Translated using Weblate (Hindi)
     new c3bf63a  import some old news posts
     new eb0a5c7  add imported news

The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.


Summary of changes:
 news/2011-11-24-archived-vfork.html.j2             | 62 ++++++++++++++++++++++
 news/2013-12-28-archived-typos-pkeys.html.j2       | 16 ++++++
 .../{oldnews-2019.html.j2 => oldnews-2011.html.j2} |  0
 .../{oldnews-2019.html.j2 => oldnews-2013.html.j2} |  0
 www.yml                                            |  6 +++
 5 files changed, 84 insertions(+)
 create mode 100644 news/2011-11-24-archived-vfork.html.j2
 create mode 100644 news/2013-12-28-archived-typos-pkeys.html.j2
 copy news/{oldnews-2019.html.j2 => oldnews-2011.html.j2} (100%)
 copy news/{oldnews-2019.html.j2 => oldnews-2013.html.j2} (100%)

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-2019.html.j2 b/news/oldnews-2011.html.j2
similarity index 100%
copy from news/oldnews-2019.html.j2
copy to news/oldnews-2011.html.j2
diff --git a/news/oldnews-2019.html.j2 b/news/oldnews-2013.html.j2
similarity index 100%
copy from news/oldnews-2019.html.j2
copy to news/oldnews-2013.html.j2
diff --git a/www.yml b/www.yml
index aefc362..76aaec9 100644
--- a/www.yml
+++ b/www.yml
@@ -198,6 +198,12 @@ newsposts:
     title: GNUnet 0.11.0pre66
     abstract:
     content:
+  - page: 2013-12-28-archived-typos-pkeys.html
+    date: 2013-12-28
+    title: Typo-Protected Public Keys
+  - page: 2011-11-24-archived-vfork.html
+    date: 2011-11-24
+    title: vfork and the signal race
 # <!-- FIXME 2015: source only available on yt. <li>Ludovic Courtès, <a 
href="">Reproducible Software Deployment with GNU Guix</a>, Inria</li> -->
 # <!-- FIXME 2014: no source link on web. <li>Julian Kirsch, <a 
href="">"Knocking down the HACIENDA"</a>, GNU Hacker Meeting 2014</li> -->
 # <!-- FIXME 2014: no source link on web. <li>Peter Schaar, <a 
href="">"Technik, Recht und Überwachung"</a>, Technische Universität 
München</li> -->

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