Arch Linux

looking at the discussion, Samuel Thibault said that is created by make install. Is true, but the way they do it, is faulty and is a bug in their system.

They don't take in consideration INSTALL_ROOT= variable used in make install

In Programs/Makefile.in the following target exists:
install-api-key:
file=$(sysconfdir)/$(API_AUTHFILE) && \
if test ! -f $$file -a -w $(sysconfdir) -a -z "$(INSTALL_ROOT)"; \
then umask 077 && $(SRC_DIR)/brltty-genkey $$file; fi

Mmm, I thought archlinux was not providing binaries and would thus not
need INSTALL_ROOT

Anyway, the problem is that it does not make sense to include
brlapi.key in a binary package: its content is supposed to be generated
at installation time and kept secret, a bit like the ssh host key
generation. Putting the value in publicly-downloadable binary packages
completely defeats the purpose of the file.

Good to see you here Samuel.

It does have a sense now after you explained, not to include the key into the package, instead I could try to generate one from /etc/rc.d/brltty using brltty-genkey.

Are you familiar on how other distros do it?

I don't know about others than Debian, which does it in a post-installation script.

@Timthy suggested that we have to add a special brltty group and /etc/brlapi.key has to be owned by root:brltty. Is it true?

I presume something like this (untested) code is the thing we want. But I really don't understand groups enough to be contributing here.

post_install(){
./brltty-genkey /etc/brlapi.key
chmod 640 /etc/brlapi.key
groupadd braille
chgrp braille /etc/brlapi.key
echo "Please add your user to the braille group."
}

It's a good idea, yes.

I am speaking from my reading of the manual: http://mielke.cc/brltty/doc/Manual-BrlAPI/English/BrlAPI-2.html#ss2.1

""Authorization.

Since Unix is designed to allow many users to work on the same machine, it's quite possible that there are more than one user accounts on the system. Most probably, one doesn't want any user with an account on the machine to be able to communicate with the braille terminal (just imagine what would happen if, while somebody was working with the braille terminal, another user connected to the system began to communicate with it, preventing the first one from doing his job...). That's why BrlAPI has to provide a way to determine whether a user who established a connection is really allowed to communicate with the braille terminal. To achieve this, BrlAPI requires that each application that wants to control a braille terminal sends an authorization key before doing anything else. The control of the braille terminal will only be possible for the client once it has sent the proper authorization key. What is called authorization key is in fact a Unix file containing data (it must be non-empty) on your system. All the things you have to do is to give read permissions on this file to users that are allowed to communicate with the braille terminal, and only to them. This way, only authorized users will have access to the authorization key and then be able to send it to BrlAPI. To see how to do that, please see chapter Installation and configuration.

At the end of this step, the user is authorized to take control of the braille terminal. On brltty's side, some data structures are allocated to store information on the client, but this has no user-level side-effect.
""

thanks for your suggestions Timothy.