[GNUnet-SVN] [gnunet-texinfo] branch master updated: philosophy.texi: added @command{}, started using two spaces between sentences.

[gnunet]

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

ng0 pushed a commit to branch master
in repository gnunet-texinfo.

The following commit(s) were added to refs/heads/master by this push:
     new 093b491  philosophy.texi: added @command{}, started using two spaces 
between sentences.
093b491 is described below

commit 093b49140ef96035e5e5d1c4191fc4139941d5f3
Author: ng0 <address@hidden>
AuthorDate: Fri Feb 17 16:57:52 2017 +0000

    philosophy.texi: added @command{}, started using two spaces between
    sentences.
---
 philosophy.texi | 94 +++++++++++++++++++++++++++------------------------------
 1 file changed, 45 insertions(+), 49 deletions(-)

diff --git a/philosophy.texi b/philosophy.texi
index 9896641..f305026 100644
--- a/philosophy.texi
+++ b/philosophy.texi
@@ -161,7 +161,7 @@ any other user.
 
 For GNUnet, efficiency is not paramount. If there is a more secure and still
 practical approach, we would choose to take the more secure alternative.
address@hidden is more efficient than @code{ssh}, yet it is obsolete.
address@hidden is more efficient than @command{ssh}, yet it is obsolete.
 Hardware gets faster, and code can be optimized. Fixing security issues as
 an afterthought is much harder. 
 
@@ -186,9 +186,9 @@ with the goals of the group is always preferable.
 @chapter Key Concepts
 @c %**end of header
 
-In this section, the fundamental concepts of GNUnet are explained. Most of
-them are also described in our research papers. First, some of the concepts
-used in the GNUnet framework are detailed. The second part describes concepts
+In this section, the fundamental concepts of GNUnet are explained.  Most of
+them are also described in our research papers.  First, some of the concepts
+used in the GNUnet framework are detailed.  The second part describes concepts
 specific to anonymous file-sharing.
 
 @node Authentication
@@ -346,21 +346,21 @@ processing, a strong adversary could try to force them to 
censor
 certain materials. 
 
 With the file-encoding used by GNUnet's anonymous file-sharing, this problem
-does not arise. The reason is that queries and replies are transmitted in
+does not arise.  The reason is that queries and replies are transmitted in
 an encrypted format such that intermediaries cannot tell what the query
-is for or what the content is about. Mind that this is not the same
-encryption as the link-encryption between the nodes. GNUnet has
+is for or what the content is about.  Mind that this is not the same
+encryption as the link-encryption between the nodes.  GNUnet has
 encryption on the network layer (link encryption, confidentiality,
 authentication) and again on the application layer (provided
-by @code{gnunet-publish}, @code{gnunet-download}, @code{gnunet-search}
-and @code{gnunet-gtk}). More details can be found here.
+by @command{gnunet-publish}, @command{gnunet-download}, @command{gnunet-search}
+and @command{gnunet-gtk}).  More details can be found here.
 
 @node Peer Identities
 @chapter Peer Identities
 @c %**end of header
 
 Peer identities are used to identify peers in the network and are unique for
-each peer. The identity for a peer is simply its public key, which is
+each peer.  The identity for a peer is simply its public key, which is
 generated along with a private key the peer is started for the first time.
 While the identity is binary data, it is often expressed as ASCII string.
 For example, the following is a peer identity as you might see it in
@@ -370,9 +370,7 @@ various places:@
 }
 
 You can find your peer identity by running@
address@hidden@
- $ gnunet-peerinfo -s@
-}
address@hidden -s}
 
 @node Zones in the GNU Name System (GNS Zones)
 @chapter Zones in the GNU Name System (GNS Zones)
@@ -381,38 +379,38 @@ You can find your peer identity by running@
 GNS zones are similar to those of DNS zones, but instead of a hierarchy of
 authorities to governing their use, GNS zones are controlled by a private key.
 When you create a record in a DNS zone, that information stored in your
-nameserver. Anyone trying to resolve your domain then gets pointed (hopefully)
-by the centralised authority to your nameserver. Whereas GNS, being
-decentralised by design, stores that information in DHT. The validity of the
+nameserver.  Anyone trying to resolve your domain then gets pointed (hopefully)
+by the centralised authority to your nameserver.  Whereas GNS, being
+decentralised by design, stores that information in DHT.  The validity of the
 records is assured cryptographically, by signing them with the private key of
 the respective zone.
 
 Anyone trying to resolve records in a zone your domain can then verify the
 signature on the records they get from the DHT and be assured that they are
-indeed from the respective zone. To make this work, there is a 1:1
-correspondence between zones and their public-private key pairs. So when we
+indeed from the respective zone.  To make this work, there is a 1:1
+correspondence between zones and their public-private key pairs.  So when we
 talk about the owner of a GNS zone, that's really the owner of the private
-key. And a user accessing a zone needs to somehow specify the corresponding
+key.  And a user accessing a zone needs to somehow specify the corresponding
 public key first.
 
 @node Egos
 @chapter Egos
 @c %**end of header
 
-Egos are your "identities" in GNUnet. Any user can assume multiple identities,
-for example to separate his activities online. Egos can correspond to
-pseudonyms or real-world identities. Technically, an ego is first of all a
+Egos are your "identities" in GNUnet.  Any user can assume multiple identities,
+for example to separate his activities online.  Egos can correspond to
+pseudonyms or real-world identities.  Technically, an ego is first of all a
 public-private key pair, and thus egos also always correspond to a GNS zone.
 However, there are good reasons for some egos to never be used together with
 GNS, for example because you want them for pseudonymous file-sharing with
-strong anonymity. Egos are managed by the IDENTITY service. Note that this
-service has nothing to do with the peer identity. The IDENTITY service
+strong anonymity.  Egos are managed by the IDENTITY service.  Note that this
+service has nothing to do with the peer identity.  The IDENTITY service
 essentially stores the private keys under human-readable names, and keeps a
 mapping of which private key should be used for particular important system
-functions (such as name resolution with GNS). If you follow the GNUnet setup,
-you will have 4 egos created by default. They can be listed by the command@
address@hidden@
- $ gnunet-identity -d@
+functions (such as name resolution with GNS).  If you follow the GNUnet setup,
+you will have 4 egos created by default.  They can be listed by the command@
address@hidden -d}@
address@hidden
  short-zone - JTDVJC69NHU6GQS4B5721MV8VM7J6G2DVRGJV0ONIT6QH7OI6D50@
  sks-zone - GO0T87F9BPMF8NKD5A54L2AH1T0GRML539TPFSRMCEA98182QD30@
  master-zone - LOC36VTJD3IRULMM6C20TGE6D3SVEAJOHI9KRI5KAQVQ87UJGPJG@
@@ -432,16 +430,16 @@ team has suffered 3 SSD crashes over a span of 2 weeks). 
Backing up peer
 identity and zones is achieved by copying the following files:
 
 The peer identity file can be found
-in @code{~/.local/share/gnunet/private_key.ecc}
+in @file{~/.local/share/gnunet/private_key.ecc}
 
 The private keys of your egos are stored in the
-directory @code{~/.local/share/gnunet/identity/egos/}. They are stored in
-files whose filenames correspond to the zones' ego names. These are
+directory @file{~/.local/share/gnunet/identity/egos/}.  They are stored in
+files whose filenames correspond to the zones' ego names.  These are
 probably the most important files you want to backup from a GNUnet
 installation.
 
 Note: All these files contain cryptographic keys and they are stored without
-any encryption. So it is advisable to backup encrypted copies of them.
+any encryption.  So it is advisable to backup encrypted copies of them.
 
 @node Revocation
 @chapter Revocation
@@ -449,43 +447,41 @@ any encryption. So it is advisable to backup encrypted 
copies of them.
 
 Now, in the situation of an attacker gaining access to the private key of
 one of your egos, the attacker can create records in the respective GNS zone
-and publish them as if you published them. Anyone resolving your domain will
+and publish them as if you published them.  Anyone resolving your domain will
 get these new records and when they verify they seem authentic because the
 attacker has signed them with your key.
 
 To address this potential security issue, you can pre-compute a revocation
-certificate corresponding to your ego. This certificate, when published on
+certificate corresponding to your ego.  This certificate, when published on
 the P2P network, flags your private key as invalid, and all further
 resolutions or other checks involving the key will fail.
 
 A revocation certificate is thus a useful tool when things go out of control,
-but at the same time it should be stored securely. Generation of the
-revocation certificate for a zone can be done through @code{gnunet-revocation}.
-For example, the following commands generates a revocation file revocation.dat
-for the zone zone1:@
address@hidden@
- $ gnunet-revocation -f revocation.dat -R zone1@
-}
-
-The above command only pre-computes a revocation certificate. It does not
-revoke the given zone. Pre-computing a revocation certificate involves
+but at the same time it should be stored securely.  Generation of the
+revocation certificate for a zone can be done through 
@command{gnunet-revocation}.
+For example, the following commands generates a revocation file 
@file{revocation.dat}
+for the zone @code{zone1}:@
address@hidden -f revocation.dat -R zone1}
+
+The above command only pre-computes a revocation certificate.  It does not
+revoke the given zone.  Pre-computing a revocation certificate involves
 computing a proof-of-work and hence may take upto 4 to 5 days on a modern
-processor. Note that you can abort and resume the calculation at any time.
+processor.  Note that you can abort and resume the calculation at any time.
 Also, even if you did not finish the calculation, the resulting file willl
 contain the signature, which is sufficient to complete the revocation
-process even without access to the private key. So instead of waiting for a
+process even without access to the private key.  So instead of waiting for a
 few days, you can just abort with CTRL-C, backup the revocation
 certificate and run the calculation only if your key actually was compromised.
 This has the disadvantage of revocation taking longer after the incident, but
-the advantage of saving a significant amount of energy. So unless you believe
+the advantage of saving a significant amount of energy.  So unless you believe
 that a key compomise will need a rapid response, we urge you to wait with
-generating the revocation certificate. Also, the calculation is deliberately
+generating the revocation certificate.  Also, the calculation is deliberately
 expensive, to deter people from doing this just for fun (as the actual
 revocation operation is expensive for the network, not for the peer performing
 the revocation).
 
 To avoid TL;DR ones from accidentally revocating their zones, I am not giving
 away the command, but its simple: the actual revocation is performed by using
-the @code{-p} option of @code{gnunet-revocation}. 
+the @command{-p} option of @command{gnunet-revocation}.
 @contents
 @bye

-- 
To stop receiving notification emails like this one, please contact
address@hidden