FETCHFILE(7)

💖 FETCHFILE 💖

okay bestie, welcome to FETCHFILE(7), a Miscellaneous Information Manual page, and it's literally all about O-SAFT / fetchfile. sit down, grab a boba, we're getting your files off a SAFT server and it's gonna be iconic 🫶

---

✨ NAME ✨

O-SAFT / fetchfile — the whole vibe in two words 💅

---

🌸 DESCRIPTION 🌸

🎀 Introduction 🎀

so there's this server protocol extension called O-SAFT (Offer Simple Asynchronous File Transfer) and a matching client called fetchfile, and together they're an easy method of retrieving files from a SAFT server. no cap. it's a direct analogy to the SMTP and POP or APOP protocol suite in the world of e-mail transfer. like, same energy, different genre 💖

overview:

• How does O-SAFT/fetchfile work?
• What to do on the client side?
• What to do on the server side?
• How about security issues?

🦋 How does O-SAFT/fetchfile work? 🦋

O-SAFT is an extension to the existing SAFT protocol and it lets authenticated clients retrieve files from a (remote) server. the implementation is the server sendfiled and the client fetchfile. periodt.

O-SAFT uses a dedicated pgp key pair to authenticate the fetchfile session. the private key stays on the client side, the public key must be present at the server side. and for security reasons this will NOT be your regular e-mail pgp key pair — it's a separate pair of pgp keys, uniquely assigned for fetchfile transfers. you will have to create a pair of pgp keys for this purpose before using the fetchfile client for the first time (see below bestie, I got you 👇).

fetchfile can provide a directory listing of available files from the server, retrieve files or delete files. and after retrieving a file, it will be placed in the regular spool directory, not in the current directory! you will have to use the receive command to transfer the files from the spool directory to your current directory afterwards. yes, it's a two-step. it's giving ✨errand✨ but it's fine.

if there already exists a regular sendfile spool directory /var/spool/sendfile on the client side it will be used, otherwise a $HOME/.sfspool will be created. fetchfile will be running without using root permissions on the client side. slay, no sudo needed 💅

💅 What to do on the client side? 💅

you must have pgp-2.6.x installed and the binaries must be available through your $PATH environment variable.

first, and ONLY ONCE before using fetchfile the very first time, you have to create a fetchfile pgp key pair (only pgp-2.6.x is supported!):

fetchfile -I

please only hit 'ENTER' when being asked for a pass phrase! this will create a special non-passphrase protected key pair for O-SAFT. no passphrase, that's the whole point 🫶

after this initialization you will have a file

/var/spool/sendfile/$USER/config/public.pgp

resp.

$HOME/.sfspool/public.pgp

please send this file to root@SAFT-server, who has to save this public key file into the appropriate user configuration directory.

example:

sendfile -c 'my O-SAFT puplic key'
/var/spool/sendfile/$USER/config/public.pgp root@bofh.belwue.de

(this preliminary action will enable you to use the SAFT server and will prevent others from abusing your name or SAFT-account on the server.)

after preparing the pgp keys on both sides, you can invoke fetchfile on a regular basis:

fetchfile -l
        list files on the server

fetchfile -a
        retrieve all files from server

fetchfile -daf *aol.com
        delete all files from the AOL domain

there is a detailed description of all capabilities in the fetchfile(1) man page. iykyk 📖

for configuring the server SAFT account by the client user there are two options:

fetchfile -Cw=config
fetchfile -Cw=restrictions

using this the two local configuration files will be transferred from the local current directory to the SAFT server. the details of the configuration can be found in the sendfile(1) man page.

with using

fetchfile -Cr=config
fetchfile -Cr=restrictions

the files will be retrieved back and will be displayed to STDOUT. ok reading it back live in your terminal? main character energy fr fr 👑

🌈 What to do on the server side? 🌈

pgp-2.6.x must be installed. the system administrator needs to run

sfdconf -e config

add set the following option:

fetchfile = on

the system administrator must create a user account (if it does not yet exist). this account does not need an interactive login shell and does not need a valid password; the login shell could be /bin/false. the only purpose is to enable the sendfiled to check out the user and to create a local spool directory (this method is well known for creating POP mail accounts). lowkey a ghost account, and we love that for it 💀

the client user will create the initial pgp key pair and the public key (public.pgp) will be sent to the system administrator of the server. this key has to be placed into the config directory for the particular user. assuming the user name is bozo, the system administrator will have to type the following (under root permissions):

receive -f bozo@* -b bozo public.pgp
su bozo
cd /var/spool/sendfile/bozo/config
receive public.pgp

(the first receive resends the file public.pgp from the sender bozo@* to the local user bozo)

🧚 How about security issues? 🧚

O-SAFT uses a tcp challenge/response authentication with a pgp signature. this opens the possibility that the session can be attacked through tcp hijacking. we are well aware of this, but tcp hijacking is not easy and only possible if the attacker has direct access to the transport media (e.g. listening on the same ethernet cable/segment) and has access to a set of pretty nice cracker tools. with regular operating system supplied software it is not possible to attack a session. so like... stay on your own ethernet segment, bestie 💅

---

👑 SEE ALSO 👑

sendfile(1), fetchfile(1), sendfiled(8).

---

💜 AUTHOR 💜

Ulli Horlacher — framstag@rus.uni-stuttgart.de

translated by andreas@citecs.de

---

okay that's the whole page bestie, you ate it up 💖 this was FETCHFILE(7) from the 3rd Berkeley Distribution, and honestly? iconic. go get those files 🦋✨🌸