Hello Administrator, 

thank you for providing the SafeWebdrop service for your users on your server.

After downloading the source code [ https://safewebdrop.com/code ]
you will find the server-side bash scripts in the server/cgi directory.
Copy or move the "safewebdrop*" scripts into your server's
cgi-bin directory and make sure they are owned by the server UID
(which may well be  48/apache).

Now you have to find a place for all the users and their encrypted
messages on your server. In version 2.0 this place would be
/home/safewebdrop. But as systemd nowadays has control over the 
httpd process, writing into /home is no longer permitted on several
distributions. So a different place has to be found.

From version 2.2 there will be a system configuration file in /etc.
As a default, the variable DEST is defined as "/var/safewebdrop".
You can use this default, or if you wish, change the value in
/etc/safewebdrop.config to the place where you will store your
user's files.

Make sure the config file /etc/safewebdrop.config is correct and readable
by your webserver process (as apache).

Move the directory "server/var/safewebdrop" into /var or the place 
you have chosen.
Make sure the directory /var/safewebdrop and /var/safewebdrop/admin
are also owned by the httpd server UID (apache) but that the script
"accept" in /var/safewebdrop/admin is owned by user root and cannot
be changed.

By now your SafeWebdrop service is installed and can be used.

You can use the SafeWebdrop message exchange for your own project
or for your Crypto Bone users.

People using your server can now register with the Crypto Bone
software on their computers. 
Once registered, they will contact you with the registration code that
your server will create during registration. Have a look in the admin
directory, you will find the user's uploaded public key and a 
file NAME.request. Check the registration code and if it matches
the information the user has given you first hand, then you can
enable the user by running "./accept NAME". This script will create
a directory for the user and copies the public key into it.

That's all you have to do, everything else is done by the server
scripts.

Your involvement stops, when you have accepted a user.

If you wish to dismiss a user, just remove their directory
from the server. Nothing more needs to be done.

#----------------------#
TESTING THE SERVER scripts

You can test whether or not all necessary server-side commands are in place
with the test program check-server-utils on your server.


To test the functionality of your SafeWebdrop service, please put all the files in the
"tests" directory on any computer that can access your server via the internet.

If you are using the program /bin/cltls to exchange data between your test computer
and your server you can go ahead without changing anything.
But be aware that the program /bin/cltls connects to a server only if either the 
fingerprint of that server is stored in the user's home directory or if a trusted
CA certificate is stored in the user's home directory. This precaution is the most
obvious advantage of cltls compared to curl.
(please refer to the manual page here: https://senderek.ie/cryptlib/tools/pdf/cltls-manual.pdf)

In order to store your server's certificate and fingerprint in the home directory
just use:

      /bin/cltls STORE your-server-name

If you wish to use /usr/bin/curl instead of the program /bin/cltls for testing purposes,
just link the bin directory to bin-curl instead of bin-cltls.

Then you can change into the bin directory and use the scripts provided to test
the SafeWebdrop functionality, before alowing any user to start secure communications.



Here are some examples

# change into the bin directory!
# register adam and eve
    ./registrationtest adam yourserver.com
    ./registrationtest eve yourserver.com

# to enable these two users on your server, run ./accept adam and ./accept eve in
# the admin directory on your server. 

# Return to your test computer

# send a message from adam to eve
    ./sendtestmessage adam yourserver.com eve yourserver.com

# read all messages for eve 
    ./gettesttarball eve yourserver.com    

# you'll find the retrieved tarball  in "../eve/TAR/tarball.tgz"
# if the tarball.tgz has more than 5 bytes (i.e. it is not empty)
# you can analyse the content and decrypt all webdrops and attachment files
    ls -l ../eve/TAR/tarball.tgz
    ./analysetarball eve

# send an attachment together with a message from eve back to adam
    cp someattachmentfile ../eve
    ./sendtestmessageandattachment eve yourserver.com adam yourserver.com someattachmentfile

# download the tarball as adam
    ./gettesttarball adam yourserver.com
    # now analyse the tarball
    # that extracts webdrops and attachments and decrypts them all
    ./analysetarball adam
    
    ls -l ../adam/TAR
    # you can now use or display the attachments as usual
    # all attachment files are now in clear text, you may change their name to reflect
    # the original filename and extension which you can find in the corresponing webdrop
    # message

#----------------------#
CROSS-SERVER COMMUNICATION

# If a third user harry is already registered by another administrator on
# a different server, adam can allow harry%otherserver.com to contact him:

    ./sendcrosspermission adam yourserver.com harry otherserver.com
    # as a result, you'll find a file harry%otherserver.com.allow 
    # in adam's contacts directory

# If harry replies with:

    ./sendcrosscontact harry otherserver.com adam yourserver.com
    # then harry's request meets adam's allow on your server and harry's public key
    # is stored in adam's contacts directory.
    # this enables secure communication from harry to adam, but not the other way around.

    # you can check this by sending:
    ./sendtestmessage harry otherserver.com adam yourserver.com

# Once harry allows adam's contact on the other server and adam requests it,
# then both users can now communicate in the same way local users can.

# If you don't want cross-server communication for your users, you can disable this
# feature in the config file on your server.

#----------------------#

NOTE, that these scripts are made only to check that everything works correctly.
Your users may use the SafeWebdrop service with the Crypto Bone GUI that handles
secure encryption keys for your users.

But of course, you can use this service for your own messaging project as well.

If you have comments or questions you can contact me directly:
https://senderek.ie/contact

#----------------------#

Thanks again for providing the SafeWebdrop service on your server.

I'd like to get your feedback, if you have some commment on this project.

Ralf Senderek
