Successfully getting an existing variable ("tinc get name") should
not result in an error exitcode (1) from the tinc command.
This changes the result of test/commandline.test from FAIL to PASS.
Some tinc commands, such as "tinc generate-keys", use the terminal to
ask the user for information. This can be bypassed by making sure
there is no terminal, which is trivial on *nix but might require
jumping through some hoops on Windows depending on how the command is
invoked.
This commit adds a --batch option that ensures tinc will never ask the
user for input, even if it is attached to a terminal.
When invoking tincd, tinc start currently uses the execvp() function,
which doesn't behave well in a console as the console displays a new
prompt before the subprocess finishes (which makes me suspect the exit
value is not handled at all). This new code uses spawnvp() instead,
which seems like a better fit.
When invoking "tinc start" with spaces in the path, the following
happens:
> "c:\Program Files (x86)\tinc\tinc.exe" start
c:\Program: unrecognized argument 'Files'
Try `c:\Program --help' for more information.
This is caused by inconsistent handling of command line strings between
execvp() and the spawned process' CRT, as documented on MSDN:
http://msdn.microsoft.com/library/431x4c1w.aspx
Instead of using a hardcoded version number in configure.ac, this makes
tinc use the live version reported by "git describe", queried on-the-fly
during the build process and regenerated for every build.
This provides several advantages:
- Less redundancy: git is now the source of truth for version
information, no need to store it in the repository itself.
- Simpler release process: just creating a git tag automatically
updates the version. No need to change files.
- More useful version information: tinc will now display the number of
commits since the last tag as well as the commit the binary is built
from, following the format described in git-describe(1).
Here's an example of tincd --version output:
tinc version release-1.1pre10-48-gc149315 (built Jun 29 2014 15:21:10, protocol 17.3)
When building directly from a release tag, this would like the following:
tinc version release-1.1pre10 (built Jun 29 2014 15:21:10, protocol 17.3)
(Note that the format is slightly different - because of the way the
tags are named, it says "release-1.1pre10" instead of just "1.1pre10")
This prevents the date and time shown in version information from
getting stale because of partial builds. With these changes, date and
time information is written to a dedicated object file that gets rebuilt
every time make is run, even if there are no changes.
In addition to the remote address, each edge now stores the local address from
the point of view of the "from" node. This information is then made available
to other nodes through a backwards-compatible extension to ADD_EDGE messages.
This information can be used in future code to improve packet routing.
When using socket functions, "sockerrno" is supposed to be used to
retrieve the error code as opposed to "errno", so that it is translated
to the correct call on Windows (WSAGetLastError() - Windows does not
update errno on socket errors). Unfortunately, the use of sockerrno is
inconsistent throughout the tinc codebase, as errno is often used
incorrectly on socket-related calls.
This commit fixes these oversights, which improves socket error
handling on Windows.
- Try to prevent SIGPIPE from being sent for errors sending to the control
socket. We don't outright block the SIGPIPE signal because we still want the
tinc CLI to exit when its output is actually sent to a real (broken) pipe.
- Don't call exit() from top(), and properly detect when the control socket is
closed by the tincd.
When creating invitations or using them to join a VPN, and the tinc command is
not run interactively (ie, when stdin and stdout are not connected or
redirected to/from a file), don't ask questions. If normally tinc would ask for
a confirmation, just assume the default answer instead. If tinc really needs
some input, just print an error message instead.
In case an invitation is used for a VPN which uses a netname that is already in
use on the local host, tinc will store the configuration in a temporary
directory. Normally it asks for an alternative netname and then renames the
temporary directory, but when not run interactively, it now just prints the
location of the unchanged temporary directory.
ListenAddress works the same as BindToAddress, except that from now on,
explicitly binding outgoing packets to the address of a socket is only done for
sockets specified with BindToAddress.
The tinc utility defered calling WSAStartup() until it tried to connect to a
running tinc daemon. However, socket functions are now also used for other
things (like joining another VPN using an invitation). Now we just
unconditionally call WSAStartup() early in main().
It seems like a lot of overhead to call access() for every possible extension
defined in PATHEXT, but apparently this is what Windows does itself too. At
least this avoids calling system() when the script one is looking for does not
exist at all.
Since the tinc utility also needs to call scripts, execute_script() is now
split off into its own source file.
As mentioned by Erik Tews, calling fchmod() after fopen() leaves a small window
for exploits. As long as tinc is single-threaded, we can use umask() instead to
reduce file permissions. This also works when creating the AF_UNIX control socket.
The umask of the user running tinc(d) is used for most files, except for the
private keys, invitation files, PID file and control socket.
In case no explicit netname of configuration directory is specified when
accepting an invitation, the netname specified in the invitation data is
used. However, this new netname is only known after making the connection
to the server. If the new netname conflicts with an existing one at the
client, we ask the user for a netname that doesn't conflict. However, we
should first finish accepting the invitation, so we don't run into the
problem that the server times out and cancels the invitation. So, we create
a random netname and store the files there, and only after we finish
accepting the invitation we ask the user for a better netname, and then
just rename the temporary directory to the final name.
If port 655 cannot be bound to when using the init command, tinc will try to
find a random port number that can be bound to, and will add the appropriate
Port variable to its host config file. A warning will be printed as well.
During the init command, tinc changed the umask to 077 when writing the public
and private key files, to prevent the temporary copies from being world
readable. However, subsequently created files would therefore also be
unreadable for others. Now we don't change the umask anymore, therefore
allowing the user to choose whether the files are world readable or not by
setting the umask as desired. The private key files are still made unreadable
for others of course. Temporary files now inherit the permissions of the
original, and the tinc-up script's permissions now also honour the umask.
Tinc now strictly limits incoming connections from the same host to 1 per
second. For incoming connections from multiple hosts short bursts of incoming
connections are allowed (by default 100), but on average also only 1 connection
per second is allowed.
When an incoming connection exceeds the limit, tinc will keep the connection in
a tarpit; the connection will be kept open but it is ignored completely. Only
one connection is in a tarpit at a time to limit the number of useless open
connections.
Some options can take an optional argument. However, in this case GNU getopt
requires that the optional argument is right next to the option without
whitespace inbetween. If there is whitespace, getopt will treat it as a
non-option argument, but tincd ignored those without a warning. Now tincd will
allow optional arguments with whitespace inbetween, and will give an error when
it encounters any other non-option arguments.
The tinc binary now requires that all options for itself are given before the
command.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.
The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.
The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.
When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
This gets rid of the rest of the symbolic links. However, as a consequence, the
crypto header files have now moved to src/, and can no longer contain
library-specific declarations. Therefore, cipher_t, digest_t, ecdh_t, ecdsa_t
and rsa_t are now all opaque types, and only pointers to those types can be
used.
