In reply to @sumanrajan435:matrix.org
Nice

How locker address autostart apps needing passwords ?

What db is in use ?

rovonovo_zoro:

How locker address autostart apps needing passwords ?

Locker obtains the password entered by the user a login (login terminal or display manager) using Pluggable Authentication Modules (PAM). This password is then used to decrypt the secrets. All this can happen immediately after login. The autostart applications will have to be started after confirming that locker is up. This is very easy to ensure if you are using systemd, s6, window managers, etc.

rovonovo_zoro:

How locker address autostart apps needing passwords ?

Locker obtains the password entered by the user at login (login terminal or display manager) using Pluggable Authentication Modules (PAM). This password is then used to decrypt the secrets. All this can happen immediately after login. The autostart applications will have to be started after confirming that locker is up. This is very easy to ensure if you are using systemd, s6, window managers, etc.

In reply to @sumanrajan435:matrix.org
Nice

How locker address autostart apps needing passwords ?

What db is in use ?

In reply to @gokuldas:matrix.org
rovonovo_zoro: In case you are curious, we won't be storing the obtained password in the memory. Instead, the password is sent through a key derivation function (Argon2id) to obtain a key hash. The password is then erased from memory and only the key hash is retained. This key hash is what is actually used to decrypt the secrets later.

rovonovo_zoro: There are still some bits to be sorted out. The leakage of the key hash is as bad as the leakage of the password as far the secrets db is concerned. However, this will at least ensure that the password is not compromised. The rest of the user account will be fine as long as the original password is protected (due to salting of password hashes).

Now, as far as the locker key hash is concerned, the OS kernel is supposed to ensure that locker's memory is not compromised. Despite all this, we need to find a way to make sure that the key hash is not written into the harddisk via the swap memory. This is still unresolved. Even then, this is a much better approach than storing the master password in a file.

Hey Suman!
I will explain what it is first before going into why I'm creating it. Locker (as it is named now) is a user service/daemon that implements the freedesktop secret service API. Such a daemon is also called a 'secrets server'. It talks to its clients over DBus. Clients include applications like Element and Evolution. These client applications use the secrets server to store their secrets - for example mail passwords or web api keys. The secrets server stores these secret credentials securely on disk for the clients to access later.

Now about why I'm implementing this. There are only 4 secrets server implementations out there. And each one has its own problem. These are listed below:

1 & 2. Gnome's gnome-keyring and KDE's kwallet. Both these programs are heavy and they implement more than just the secret service. They also work as (unsatisfactory) gpg-agent and ssh-agent. This means that you can't run the real gpg-agent or ssh-agent if one of these is running. This is a problem for those who want to run the real agents - especially those who work on window managers like i3, sway, awesome, etc. This is why a standalone secrets server is necessary. In addition to this problem, both of them are heavily dependent on the DE libraries and pull a large number of dependencies while installing. Furthermore, it's extremely hard to disable gnome-keyring as long as it is installed on the system.

1. KeePassXC. This is a GUI password manager that can also work as a secrets server. However, you need to unlock the password DB manually before the stored secrets are available through the DBus API. This is a problem for autostart applications like nextcloud-client and mail syncers. We really need a headless daemon that goes up before these applications are launched.
2. Secret Service by yousefvand: It solves all the problems above, but creates a new one. It doesn't store the secrets securely. Any application can trivially access the master password file and unlock all secrets. This is an acknowledged problem. However, there seems to be no plans to address it. With Locker, I instead plan to access the user's account password through PAM and use it to encrypt and decrypt the secrets to a database.

Hope I'm clear enough. Let me know if you have more questions.

rovonovo_zoro: There are still some bits to be sorted out. The leakage of the key hash is as bad as the leakage of the password as far the secrets db is concerned. However, this will at least ensure that the password is not compromised. The rest of the user account will be fine as long as the original password is protected (due to salting of password hashes).

Now, as far as the locker key hash is concerned, the OS kernel is supposed to ensure that locker's memory is not compromised. Despite all this, we need to find a way to make sure that the key hash is not written into the harddisk via the swap memory. This is still unresolved. Even so, this is a much better approach than storing the master password in a file.

In reply to @athulvis1:matrix.org
@goku12 you have shared a set of tools to sync up contacts and messages from phone to some server. Is it possible to share it again?

In reply to @mdhav:matrix.org
Any provider or do you host yourself?

In reply to @famubu:matrix.org
Was windowshopping some sites selling/renting domain names. Saw some places offering big discout if we buy it for 10 years at once. Do you guys know what the risks associated with that option could be?

In reply to @gokuldas:matrix.org
10 years is the maximum any domain can be registered for in a go