| Age | Commit message (Collapse) | Author |
|---|
|
|
|
there is a combination that was failing, with a recent-enough version of
cryptography coming from jessie-backports (>1.0), but still being linked
to openssl 1.0 which does not have a usable scrypt backend.
with this commit we fallback on doing scrypt using python's scrypt
package.
|
|
|
|
|
|
leap.common 0.6.0 renamed this method.
we should think about not using the factory directly, since we want to
deprecate leap.common.http
|
|
This needs OpenSSL >= 1.1, otherwise it will keep using the scrypt
dependency.
We should think about deprecating scrypt as a dependency when we can be
sure that the adoption of libssl 1.1 is wide enough. I think that at
some point (soledad 0.11 or so) we can drop the scrypt dependency, which
was being somehow problematic at times (the _scrypt.so was not appearing
when installing with pip, needed workarounds). From that moment on, we
can raise an error if an old libssl is found and no scrypt can be
imported - leaving that to the user/packager.
In debian stretch and afterwards, you can get that version by installing
libssl-dev
- Related: #8472
|
|
|
|
|
|
|
|
We have been discussing about this merge for a while.
Its main goal is to simplify things: code navigation, but also
packaging.
The rationale is that the code is more cohesive in this way, and there's
only one source package to install.
Dependencies that are only for the server or the client will not be
installed by default, and they are expected to be provided by the
environment. There are setuptools extras defined for the client and the
server.
Debianization is still expected to split the single source package into
3 binaries.
Another avantage is that the documentation can now install a single
package with a single step, and therefore include the docstrings into
the generated docs.
- Resolves: #8896
|
