Tests:
- Build developer documentation and ensure that there are no errors during build
and all changes are reflected.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Joseph Nuthalapati <njoseph@riseup.net>
- In current stable and testing, verifying SSH remote hosts using RSA is not
working. After selecting the verified RSA fingerprint, paramiko fails to connect
- A change introduced in paramiko 2.9 lead to failures when connecting to hosts
that have a verified RSA host key[1][2][3]. To fix the issue,
disabled_algorithms must be used to drop some of the other algorithms supported
by the server to force paramiko behavior. A better solution to the problem was
introduced in paramiko 3.2. Both these solutions require careful update to the
code. Considering the utility paramiko provides, the regression annoyance,
effort required for this fix, and the security implications (it is an completely
independent SSH implementation), the library does not seem to be worth the
effort in our case.
- Switch to using sshpass command line utility instead of paramiko library. The
only reason to use paramiko seems that 'ssh' command by default does not allow
us to input password easily while paramiko does.
- Another place where paramiko is being used is to check if a host is already
verified in the known_hosts file. This has been trivially replaced with
'ssh-keygen -F'.
- Exit codes provided by sshpass can replace the specific exception raised by
paramiko.
Links:
1) https://www.paramiko.org/changelog.html
2) https://github.com/paramiko/paramiko/issues/2017
3) https://github.com/paramiko/paramiko/issues/1984
Tests:
- Add a remote backup repository with and without encryption.
- Add remote backup repository with all three types of algorithms.
- Add a remote repository again with wrong password. Authentication error is
properly shown.
- Add a remote backup repository and remove it. Host remains verified. Add a
repository again.
- Add a remote backup repository and remove it. Host remains verified. Change
the fingerprint the /var/lib/plinth/.ssh/known_hosts file. Add a repository
again. A proper error is shown that remote host could not be verified.
- Add a remote backup repository and remove it. Host remains verified. Stop SSH
server on the remote host. A generic error is shown that ssh command on remote
host failed.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
Closes: Debian bug #1088760.
- OpenSSL.crypto.sign has been deprecated and in the current version of
python3-openssl in Debian testing, it has been dropped. The recommended
alternative is cryptography.hazmat.primitives. So, use this instead.
- The entire OpenSSL.crypto module is planned to be deprecated in the future.
So, stop using it entirely by using cryptography.hazmat.primitives.
- sso app does not use openssl anymore, so drop dependency on it. Other apps
such as Let's Encrypt do depend on it and but they have their own dependency
declared. The freedombox package on the overall retains on 'openssl' package.
- We are not using the python OpenSSL module anywhere else, so drop dependency
on it.
- Use pathlib to simplify some code.
- Ensure proper permissions on private and public keys as they are being written
to.
Tests:
- Freshly setup container and ensure that first run succeeds. Permission on the
public/private key files and the parent directly are correct. Users are able
login to FreedomBox. SSO works when accessing apps such as transmission.
- Without patches, setup freedombox container. Apply patches. Permission for
keys directory is updated but keys are not overwritten. Login to FreedomBox
works. SSO works when accessing apps such as transmission.
- Run code to perform signatures using old code and ensure that newer code
generates bit-identical signatures.
- Running ./run --list-dependencies show 'openssl' and python3-cryptography.
- Running unit tests works.
- Building debian package works.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Joseph Nuthalapati <njoseph@riseup.net>
Closes: #2405.
- When Django module is mocked, there are some cases where modules using django
can't be imported due to errors.
- To fix that, don't mock the django module and require django and related
Debian packages to be installed on the system generate developer documentation.
- Initialize django in Sphinx configuration to allow django modules to be
imported without errors.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
