summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorChristian Grothoff <christian@grothoff.org>2021-04-26 17:28:56 +0200
committerChristian Grothoff <christian@grothoff.org>2021-04-26 17:28:56 +0200
commit82a5d35360c4c882d9a5f92c4ac27c61bd4a4cc5 (patch)
tree8c50e8d74033214e711929c3244e5aca34f9705f /doc
parent51c0c5072fa27f4964778512a0040c77cce7cd04 (diff)
-fix misc typos
Diffstat (limited to 'doc')
-rw-r--r--doc/handbook/chapters/developer.texi179
-rw-r--r--doc/handbook/chapters/installation.texi4
-rw-r--r--doc/man/gnunet-gns.12
-rw-r--r--doc/man/gnunet-testbed-profiler.12
-rw-r--r--doc/man/gnunet-timeout.12
-rw-r--r--doc/man/gnunet.conf.5.in10
-rw-r--r--doc/release_policy.rfc.txt16
-rw-r--r--doc/system_specific/FROM_SOURCE6
8 files changed, 110 insertions, 111 deletions
diff --git a/doc/handbook/chapters/developer.texi b/doc/handbook/chapters/developer.texi
index 1bf7a7b24..7546f7ac7 100644
--- a/doc/handbook/chapters/developer.texi
+++ b/doc/handbook/chapters/developer.texi
@@ -8885,7 +8885,7 @@ block is more recent during the store operation.
The REVOCATION subsystem is responsible for key revocation of Egos.
-If a user learns that theis private key has been compromised or has lost
+If a user learns that their private key has been compromised or has lost
it, they can use the REVOCATION system to inform all of the other users
that their private key is no longer valid.
The subsystem thus includes ways to query for the validity of keys and to
@@ -9782,61 +9782,61 @@ attempt to retransmit them.
@node MESSENGER Subsystem
@section MESSENGER Subsystem
-The MESSENGER subsystem is responsible for secure end-to-end communication in
+The MESSENGER subsystem is responsible for secure end-to-end communication in
groups of nodes in the GNUnet overlay network. MESSENGER builds on the CADET
-subsystem which provides a reliable and secure end-to-end communication between
+subsystem which provides a reliable and secure end-to-end communication between
the nodes inside of these groups.
-Additionally to the CADET security benefits, MESSENGER provides following
+Additionally to the CADET security benefits, MESSENGER provides following
properties designed for application level usage:
@itemize @bullet
-@item MESSENGER provides integrity by signing the messages with the users
+@item MESSENGER provides integrity by signing the messages with the users
provided ego
-@item MESSENGER adds (optional) forward secrecy by replacing the key pair of the
- used ego and signing the propagation of the new one with old one (chaining
+@item MESSENGER adds (optional) forward secrecy by replacing the key pair of the
+ used ego and signing the propagation of the new one with old one (chaining
egos)
@item MESSENGER provides verification of a original sender by checking against
- all used egos from a member which are currently in active use (active use
+ all used egos from a member which are currently in active use (active use
depends on the state of a member session)
@item MESSENGER offsers (optional) decentralized message forwarding between all
nodes in a group to improve availability and prevent MITM-attacks
-@item MESSENGER handles new connections and disconnections from nodes in the
- group by reconnecting them preserving an efficient structure for message
+@item MESSENGER handles new connections and disconnections from nodes in the
+ group by reconnecting them preserving an efficient structure for message
distribution (ensuring availability and accountablity)
-@item MESSENGER provides replay protection (messages can be uniquely identified
+@item MESSENGER provides replay protection (messages can be uniquely identified
via SHA-512, include a timestamp and the hash of the last message)
-@item MESSENGER allows detection for dropped messages by chaining them (messages
+@item MESSENGER allows detection for dropped messages by chaining them (messages
refer to the last message by their hash) improving accountability
@item MESSENGER allows requesting messages from other peers explicitly to ensure
availability
@item MESSENGER provides confidentiality by padding messages to few different
- sizes (512 bytes, 4096 bytes, 32768 bytes and maximal message size from
+ sizes (512 bytes, 4096 bytes, 32768 bytes and maximal message size from
CADET)
@item MESSENGER adds (optional) confidentiality with ECDHE to exchange and use
- symmetric encryption, encrypting with both AES-256 and Twofish but
- allowing only selected members to decrypt (using the receivers ego for
+ symmetric encryption, encrypting with both AES-256 and Twofish but
+ allowing only selected members to decrypt (using the receivers ego for
ECDHE)
@end itemize
Also MESSENGER provides multiple features with privacy in mind:
@itemize @bullet
-@item MESSENGER allows deleting messages from all peers in the group by the
+@item MESSENGER allows deleting messages from all peers in the group by the
original sender (uses the MESSENGER provided verification)
@item MESSENGER allows using the publicly known anonymous ego instead of any
unique identifying ego
-@item MESSENGER allows your node to decide between acting as host of the used
- messaging room (sharing your peer's identity with all nodes in the group)
+@item MESSENGER allows your node to decide between acting as host of the used
+ messaging room (sharing your peer's identity with all nodes in the group)
or acting as guest (sharing your peer's identity only with the nodes you
explicitly open a connection to)
-@item MESSENGER handles members independently of the peer's identity making
+@item MESSENGER handles members independently of the peer's identity making
forwarded messages indistinguishable from directly received ones (
complicating the tracking of messages and identifying its origin)
-@item MESSENGER allows names of members being not unique (also names are
+@item MESSENGER allows names of members being not unique (also names are
optional)
-@item MESSENGER does not include information about the selected receiver of an
- explicitly encrypted message in its header, complicating it for other
+@item MESSENGER does not include information about the selected receiver of an
+ explicitly encrypted message in its header, complicating it for other
members to draw conclusions from communication partners
@end itemize
@@ -9848,71 +9848,71 @@ Also MESSENGER provides multiple features with privacy in mind:
@node libgnunetmessenger
@subsection libgnunetmessenger
-The MESSENGER API (defined in @file{gnunet_messenger_service.h}) allows P2P
+The MESSENGER API (defined in @file{gnunet_messenger_service.h}) allows P2P
applications built using GNUnet to communicate with specified kinds of messages
in a group. It provides applications the ability to send and receive encrypted
messages to any group of peers participating in GNUnet in a decentralized way (
without even knowing all peers's identities).
-MESSENGER delivers messages to other peers in "rooms". A room uses a variable
-amount of CADET "channels" which will all be used for message distribution. Each
-channel can represent an outgoing connection opened by entering a room with
-@code{GNUNET_MESSENGER_enter_room} or an incoming connection if the room was
+MESSENGER delivers messages to other peers in "rooms". A room uses a variable
+amount of CADET "channels" which will all be used for message distribution. Each
+channel can represent an outgoing connection opened by entering a room with
+@code{GNUNET_MESSENGER_enter_room} or an incoming connection if the room was
opened before via @code{GNUNET_MESSENGER_open_room}.
@image{images/messenger_room,6in,,Room structure}
-To enter a room you have to specify the "door" (peer's identity of a peer which
-has opened the room) and the key of the room (which is identical to a CADET
-"port"). To open a room you have to specify only the key to use. When opening a
-room you automatically distribute a PEER-message sharing your peer's identity in
+To enter a room you have to specify the "door" (peer's identity of a peer which
+has opened the room) and the key of the room (which is identical to a CADET
+"port"). To open a room you have to specify only the key to use. When opening a
+room you automatically distribute a PEER-message sharing your peer's identity in
the room.
-Entering or opening a room can also be combined in any order. In any case you
-will automatically get a unique member ID and send a JOIN-message notifying
+Entering or opening a room can also be combined in any order. In any case you
+will automatically get a unique member ID and send a JOIN-message notifying
others about your entry and your public key from your selected ego.
-The ego can be selected by name with the initial @code{GNUNET_MESSENGER_connect}
-besides setting a (identity-)callback for each change/confirmation of the used
-ego and a (message-)callback which gets called every time a message gets sent or
-received in the room. Once the identity-callback got called you can check your
-used ego with @code{GNUNET_MESSENGER_get_key} providing only its public key. The
-function returns NULL if the anonymous ego is used. If the ego should be
-replaced with a newly generated one, you can use @code{GNUNET_MESSENGER_update}
+The ego can be selected by name with the initial @code{GNUNET_MESSENGER_connect}
+besides setting a (identity-)callback for each change/confirmation of the used
+ego and a (message-)callback which gets called every time a message gets sent or
+received in the room. Once the identity-callback got called you can check your
+used ego with @code{GNUNET_MESSENGER_get_key} providing only its public key. The
+function returns NULL if the anonymous ego is used. If the ego should be
+replaced with a newly generated one, you can use @code{GNUNET_MESSENGER_update}
to ensure proper chaining of used egos.
-Also once the identity-callback got called you can check your used name with
-@code{GNUNET_MESSENGER_get_name} and potentially change or set a name via
-@code{GNUNET_MESSENGER_set_name}. A name is for example required to create a new
-ego with @code{GNUNET_MESSENGER_update}. Also any change in ego or name will
-automatically be distributed in the room with a NAME- or KEY-message
+Also once the identity-callback got called you can check your used name with
+@code{GNUNET_MESSENGER_get_name} and potentially change or set a name via
+@code{GNUNET_MESSENGER_set_name}. A name is for example required to create a new
+ego with @code{GNUNET_MESSENGER_update}. Also any change in ego or name will
+automatically be distributed in the room with a NAME- or KEY-message
respectively.
-To send a message a message inside of a room you can use
-@code{GNUNET_MESSENGER_send_message}. If you specify a selected contact as
-receiver, the message gets encrypted automatically and will be sent as PRIVATE-
+To send a message a message inside of a room you can use
+@code{GNUNET_MESSENGER_send_message}. If you specify a selected contact as
+receiver, the message gets encrypted automatically and will be sent as PRIVATE-
message instead.
-To request a potentially missed message or to get a specific message after its
-original call of the message-callback, you can use
-@code{GNUNET_MESSENGER_get_message}. Additionally once a message was distributed
-to application level and the message-callback got called, you can get the
-contact respresenting a message's sender respectively with
-@code{GNUNET_MESSENGER_get_sender}. This allows getting name and the public key
-of any sender currently in use with @code{GNUNET_MESSENGER_contact_get_name}
-and @code{GNUNET_MESSENGER_contact_get_key}. It is also possible to iterate
-through all current members of a room with
+To request a potentially missed message or to get a specific message after its
+original call of the message-callback, you can use
+@code{GNUNET_MESSENGER_get_message}. Additionally once a message was distributed
+to application level and the message-callback got called, you can get the
+contact respresenting a message's sender respectively with
+@code{GNUNET_MESSENGER_get_sender}. This allows getting name and the public key
+of any sender currently in use with @code{GNUNET_MESSENGER_contact_get_name}
+and @code{GNUNET_MESSENGER_contact_get_key}. It is also possible to iterate
+through all current members of a room with
@code{GNUNET_MESSENGER_iterate_members} using a callback.
-To leave a room you can use @code{GNUNET_MESSENGER_close_room} which will also
-close the rooms connections once all applications on the same peer have left
-the room. Leaving a room will also send a LEAVE-message closing a member session
-on all connected peers before any connection will be closed. Leaving a room is
-however not required for any application to keep your member session open
+To leave a room you can use @code{GNUNET_MESSENGER_close_room} which will also
+close the rooms connections once all applications on the same peer have left
+the room. Leaving a room will also send a LEAVE-message closing a member session
+on all connected peers before any connection will be closed. Leaving a room is
+however not required for any application to keep your member session open
between multiple sessions of the actual application.
-Finally, when an application no longer wants to use CADET, it should call
-@code{GNUNET_MESSENGER_disconnect}. You don't have to explicitly close the used
+Finally, when an application no longer wants to use CADET, it should call
+@code{GNUNET_MESSENGER_disconnect}. You don't have to explicitly close the used
rooms or leave them.
Here is a little summary to the kinds of messages you can send manually:
@@ -9928,33 +9928,33 @@ Here is a little summary to the kinds of messages you can send manually:
@node MERGE-message
@subsubsection MERGE-message
-MERGE-messages will generally be sent automatically to reduce the amount of
-parallel chained messages. This is necessary to close a member session for
-example. You can also send MERGE-messages manually if required to merge two
+MERGE-messages will generally be sent automatically to reduce the amount of
+parallel chained messages. This is necessary to close a member session for
+example. You can also send MERGE-messages manually if required to merge two
chains of messages.
@node INVITE-message
@subsubsection INVITE-message
-INVITE-messages can be used to invite other members in a room to a different
-room, sharing one potential door and the required key to enter the room. This
-kind of message is typically sent as encrypted PRIVATE-message to selected
-members because it doesn't make much sense to invite all members from one room
+INVITE-messages can be used to invite other members in a room to a different
+room, sharing one potential door and the required key to enter the room. This
+kind of message is typically sent as encrypted PRIVATE-message to selected
+members because it doesn't make much sense to invite all members from one room
to another considering a rooms key doesn't specify its usage.
@node TEXT-message
@subsubsection TEXT-message
-TEXT-messages can be used to send simple text-based messages and should be
-considered as being in readable form without complex decoding. The text has to
-end with a NULL-terminator character and should be in UTF-8 encoding for most
+TEXT-messages can be used to send simple text-based messages and should be
+considered as being in readable form without complex decoding. The text has to
+end with a NULL-terminator character and should be in UTF-8 encoding for most
compatibility.
@node FILE-message
@subsubsection FILE-message
-FILE-messages can be used to share files inside of a room. They do not contain
-the actual file being shared but its original hash, filename, URI to download
+FILE-messages can be used to share files inside of a room. They do not contain
+the actual file being shared but its original hash, filename, URI to download
the file and a symmetric key to decrypt the downloaded file.
It is recommended to use the FS subsystem and the FILE-messages in combination.
@@ -9962,30 +9962,29 @@ It is recommended to use the FS subsystem and the FILE-messages in combination.
@node DELETE-message
@subsubsection DELETE-message
-DELETE-messages can be used to delete messages selected with its hash. You can
-also select any custom delay relative to the time of sending the DELETE-message.
-Deletion will only be processed on each peer in a room if the sender is
+DELETE-messages can be used to delete messages selected with its hash. You can
+also select any custom delay relative to the time of sending the DELETE-message.
+Deletion will only be processed on each peer in a room if the sender is
authorized.
-The only information of a deleted message which being kept will be the chained
+The only information of a deleted message which being kept will be the chained
hashes connecting the message graph for potential traversion. For example the
check for completion of a member session requires this information.
@node Member sessions
@subsection Member sessions
-A member session is a triple of the room key, the member ID and the public key
-of the member's ego. Member sessions allow that a member can change their ID or
-their ego once at a time without losing the ability to delete old messages or
-identifying the original sender of a message. On every change of ID or EGO a
-session will be marked as closed. So every session chain will only contain one
+A member session is a triple of the room key, the member ID and the public key
+of the member's ego. Member sessions allow that a member can change their ID or
+their ego once at a time without losing the ability to delete old messages or
+identifying the original sender of a message. On every change of ID or EGO a
+session will be marked as closed. So every session chain will only contain one
open session with the current ID and public key.
-If a session is marked as closed the MESSENGER service will check from the first
-message opening a session to its last one closing the session for completion. If
-a the service can confirm that there is no message still missing which was sent
+If a session is marked as closed the MESSENGER service will check from the first
+message opening a session to its last one closing the session for completion. If
+a the service can confirm that there is no message still missing which was sent
from the closed member session, it will be marked as completed.
-A completed member session is not able to verify any incoming message to ensure
+A completed member session is not able to verify any incoming message to ensure
forward secrecy preventing others from using old stolen egos.
-
diff --git a/doc/handbook/chapters/installation.texi b/doc/handbook/chapters/installation.texi
index 24431e20f..54fb3f486 100644
--- a/doc/handbook/chapters/installation.texi
+++ b/doc/handbook/chapters/installation.texi
@@ -1533,7 +1533,7 @@ Now restart your webserver and your peer...
@subsection Blacklisting peers
Transport service supports to deny connecting to a specific peer of to a
-specific peer with a specific transport plugin using te blacklisting
+specific peer with a specific transport plugin using the blacklisting
component of transport service. With@ blacklisting it is possible to deny
connections to specific peers of@ to use a specific plugin to a specific
peer. Peers can be blacklisted using@ the configuration or a blacklist
@@ -1560,7 +1560,7 @@ To blacklist connections to P565... on peer AG2P... using all plugins add:
P565723JO1C2HSN6J29TAQ22MN6CI8HTMUU55T0FUQG4CMDGGEQ8UCNBKUMB94GC8R9G4FB2SF9LDOBAJ6AMINBP4JHHDD6L7VD801G =
@end example
-You can also add a blacklist client usign the blacklist API. On a
+You can also add a blacklist client using the blacklist API. On a
blacklist check, blacklisting first checks internally if the peer is
blacklisted and if not, it asks the blacklisting clients. Clients are
asked if it is OK to connect to a peer ID, the plugin is omitted.
diff --git a/doc/man/gnunet-gns.1 b/doc/man/gnunet-gns.1
index 5595981b0..de48369f5 100644
--- a/doc/man/gnunet-gns.1
+++ b/doc/man/gnunet-gns.1
@@ -64,7 +64,7 @@ Resolve the specified name using the GNU Name System.
.It Fl T Ar TIMEOUT | Fl -timeout= Ns Ar TIMEOUT
How much time to wait for a resolution to finish.
Example: "5s" for 5 seconds or "3m" for 3 minutes.
-Defaults to "forver" (No timeout).
+Defaults to "forever" (No timeout).
.It Fl v | -version
Print GNUnet version number.
.El
diff --git a/doc/man/gnunet-testbed-profiler.1 b/doc/man/gnunet-testbed-profiler.1
index b39544641..d079609ad 100644
--- a/doc/man/gnunet-testbed-profiler.1
+++ b/doc/man/gnunet-testbed-profiler.1
@@ -46,7 +46,7 @@ is a command line profiling driver for the testbed.
.It Fl c Ar FILENAME | Fl -config= Ns Ar FILENAME
Use the configuration file FILENAME.
.It Fl e Ar COUNT | Fl -num-errors= Ns Ar COUNT
-Tolerate COUNT number of continious timeout failures.
+Tolerate COUNT number of continuous timeout failures.
.It Fl H Ar FILENAME | Fl -hosts= Ns Ar FILENAME
Name of the file with the login information for the testbed.
.It Fl h | -help
diff --git a/doc/man/gnunet-timeout.1 b/doc/man/gnunet-timeout.1
index a36141c36..85ecc88c1 100644
--- a/doc/man/gnunet-timeout.1
+++ b/doc/man/gnunet-timeout.1
@@ -35,7 +35,7 @@
.Sh DESCRIPTION
.Nm
can be used to run another process with a timeout.
-It is provided because the standard "timout" utility may not be available on all platforms.
+It is provided because the standard "timeout" utility may not be available on all platforms.
.Sh SEE ALSO
.Xr timeout 1
.sp
diff --git a/doc/man/gnunet.conf.5.in b/doc/man/gnunet.conf.5.in
index 116e7de3b..19136b849 100644
--- a/doc/man/gnunet.conf.5.in
+++ b/doc/man/gnunet.conf.5.in
@@ -54,7 +54,7 @@ encountered.
.It
A section contains a number of options of the form "OPTION=VALUE".
.It
-Whitespace surounding the "=" token is striped out, in other words
+Whitespace surrounding the "=" token is striped out, in other words
"OPTION = VALUE" and "OPTION=VALUE" are treated equal.
.It
Empty lines and lines beginning with a "#" are treated as comments.
@@ -166,7 +166,7 @@ Set to NO if this is a system service.
In the following sections the absence of a default value is either
expressed as "Default value:" followed by nothing, or the lack of this line.
.Ss ARM
-.Bl -tag -width indent
+.Bl -tag -width indent
.It PORT
Default value: 2087
.It HOSTNAME
@@ -215,7 +215,7 @@ options differ.
If set to YES, ARM will only start services that are marked as per-user
services (and we'll expect a system user to run ARM to provide system-level
services).
-Per-user services enable better personalization and priviledge separation and
+Per-user services enable better personalization and privilege separation and
in particular ensures that personal data is stored under $HOME, which might be
important in a multi-user system (or if $HOME is encrypted and
.Pa /var/
@@ -321,7 +321,7 @@ Default value: 2.00
.It 1.0
Fair with respect to addresses without preferences.
.It > 1.0
-The bigger, the more respect is payed to preferences.
+The bigger, the more respect is paid to preferences.
.El
.It PROP_STABILITY_FACTOR
Should we stick to existing connections are prefer to switch?
@@ -430,7 +430,7 @@ Default value: 5 min
Percentage of packets CADET is artificially dropping.
Used for testing only!
.It ID_ANNOUNCE_TIME
-How frequently do we usually anounce our presence in the DHT?
+How frequently do we usually announce our presence in the DHT?
.Pp
Default value: 1 h
.It CONNECT_TIMEOUT
diff --git a/doc/release_policy.rfc.txt b/doc/release_policy.rfc.txt
index 41c98ec93..e13e72f43 100644
--- a/doc/release_policy.rfc.txt
+++ b/doc/release_policy.rfc.txt
@@ -7,17 +7,17 @@ social process in order to find a decision in a cooperativ and common
way.
-I. Driver
+I. Driver
=========
(What is the problem and what solution did we find?)
In the past it was sometimes unclear when and how the community would reach its
-next release. Members were lacking in orientation and felt demotivated.
+next release. Members were lacking in orientation and felt demotivated.
Another minor concern not yet analysed in depth was the expectation to show the
public that the GNUnet project is still active and making progress. With an old
release distributed by popular linux distributions it was hard to showcase
-people the GNUnet features and encourage to participate in the project.
+people the GNUnet features and encourage to participate in the project.
To show people how the GNUnet project is releasing its software we hereby
document the current release model:
@@ -55,7 +55,7 @@ document the current release model:
For further information see: https://trunkbaseddevelopment.com/
-II. Evaluation Criteria
+II. Evaluation Criteria
=======================
(what are criteria to interpret the results as success if we review
the problem and solution after a year or so)
@@ -74,7 +74,7 @@ code. I don't have a magic bullet to motivate you to write more tests,
or to improve existing tests. -CG
Your argument is good. Two or three of us thought that the problem is about
- missing releases which we feld demotivating. We thought, we were stuck
+ missing releases which we felt demotivating. We thought, we were stuck
somewhere. But as you state, it is us not doing the necessary work. What I
still find useful is to document the release process. In consequence I
changed the problem statement. -xrs
@@ -106,7 +106,7 @@ for improving that situation). -CG
With resprect to changes kept in branches the reason why I personally keep
changes back is because it takes very long for me to get something really
working in C. Before that I either not worth it or I don't want to blame
- other before not being sure it's not my fault.
+ other before not being sure it's not my fault.
Can we track branches? Can we write a little cronjob that checks for branches
that are to long undercover with the aim to recommend the responsible person
@@ -137,7 +137,7 @@ rewrites are happening, it is important to minimize the number of
branches. -CG
Thank you for clarifying. I added the API aspect above. -xrs
-
+
IV. Doing
=========
@@ -153,7 +153,7 @@ Let me list what I think needs doing:
2) A culture of fixing "other people"'s bugs: test case failures,
portability issues, Mantis reports, all the non-sexy
stuff. Not the 'psycstore' was written by tg, so no
- need for !tg to try to fix it, or the "I use sqlite,
+ need for !tg to try to fix it, or the "I use sqlite,
why should I bother with postgres?"-crap I have heard
too often.
3) Improving test cases: better code coverage, more corner
diff --git a/doc/system_specific/FROM_SOURCE b/doc/system_specific/FROM_SOURCE
index 7b0ebf436..2e98ab5c0 100644
--- a/doc/system_specific/FROM_SOURCE
+++ b/doc/system_specific/FROM_SOURCE
@@ -204,7 +204,7 @@ $ gnunet-arm -s
@subsection Install the GNUnet-gtk user interface from Git
-Install depencies:
+Install dependencies:
@example
$ sudo apt-get install libgtk-3-dev libunique-3.0-dev libgladeui-dev \
@@ -866,7 +866,7 @@ This means that you have to make sure the proper tools are used in the build pro
For example, after installing texinfo you need to make sure the new texinfo is actually used:
@example
-$ echo 'export PATH="/usr/local/opt/texinfo/bin:$PATH"' >> ~/.bash_profile
+$ echo 'export PATH="/usr/local/opt/texinfo/bin:$PATH"' >> ~/.bash_profile
@end example
Note: brew tells you the appropriate command when executing
@@ -886,7 +886,7 @@ $ export CC=gcc-7
You might see configure failing telling you that it ``cannot run C compiled programs.''.
In this case, you might need to open/run Xcode once and you will be prompted to
-install additonal packages.
+install additional packages.
Then, you might have to manually install the command line tools from here https://developer.apple.com/download/more/ (you need an Apple ID for this).
Install those and execute