| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
In some cases in the past keys got stored twice in different documents.
Hopefully this issue is solved now, this tries to self-repair the keyring
if encounters that. This is not really solving the problem, if it keeps
happening we need to investigate the source.
- Resolves: #7498
|
|
The latests refactor missed one line.
|
|
Improve readability of operations on generic keys, by assigning the
class matching the type of key (_wrapper_map[ktype]) at the beginning of
each block.
in the future, we could pass the type of key (only PGP keys being used
at the moment) on initialization of the Keymanager, so we don't have to
pass the ktype on each method call.
|
|
so that it can be tested without needing to instantiate the whole
OpenPGPScheme object, that receives a soledad instance.
|
|
|
|
|
|
In previous commit 9546348c, the combined bundle ca
was not long enough in scope and was therefore deleted
when it actually was used.
Adopted test to check whether file is deleted.
|
|
Fails if wrong address is passed to the put_key method,
or wrong key is marked as sign_used.
- Related: #7420
|
|
During decryption the signing public key was getting repush with a
different address as part of the verify usage flagging.
- Resolves: https://github.com/pixelated/pixelated-user-agent/issues/466
- Related: #7420
|
|
|
|
Fixup for 9546348c36. This problem only occurs in
test setups where '' is passed to ca_cert_path.
|
|
On fetch_key we were not catching the request exceptions, now they are
returned as failure in the deferred as it should.
- Related: #7410
|
|
|
|
|
|
This is necessary as a fetch by url will talk to remote
sites or, for providers with a commercial cert, with
a cert that had not been signed with the provider CA.
- support lookup of local keys by url for providers
with a commercial cert
- combine ca_bundle with ca_cert_path if specified
- close soledad after each test
|
|
In case of failure of fetch_key will be useful to have some logging
telling us wich key is fetching.
- Related: #7410
|
|
|
|
this avoids using a separate thread with tornado ioloop for events
client, since we can use twisted reactor.
- Resolves: #7274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--use-leap-wheels sets --trusted-host (remove it when we have a proper
cert) and WHEELHOUSE to https://ftp.lizard.leap.se
Until we get ftp.lizard cname, use lizard as the wheels server.
Related: #7339
|
|
|
|
That's an easy way to setup the latest develop without
depending on manually downloading the dependencies
|
|
Fixed pep8 warnings to prepare the keymanager for CI
|
|
generate_wheels uses $WHEELHOUSE to generate and store the wheels for
requirements.pip and requirements-testing.pip (if it exists).
pip_install_requirements.sh installs requirements.pip from them if
possible (if not, then it fetches them from pypi) or, if passed the
--testing flag, it installs requirements-testing.pip.
Related: #7327
|
|
|
|
|
|
|
|
- update pip
- install base reqs
|
|
otherwise, the tests will be pulling outdated versions from pypi.
|
|
latest gnupg version (from pypi) was '2.0.2-py2.7.egg', which is parsed
as a LegacyVersion and therefore breaks the numeric comparison. this is
a workaround to allow the sanity check to continue, by comparing just
the numeric part of the version string.
|
|
it is the responsibility of the developer to install them now
- Related: #7288
|
|
|
|
this is part of a process to make the setup of the development mode less
troublesome. from now on, setting up a virtualenv in pure development
mode will be as easy as telling pip to just install the external
dependencies::
pip install -r pkg/requirements.pip
and traversing all the leap repos for the needed leap dependencies doing::
python setup.py develop
- Related: #7288
|
|
|
|
|
|
* Resolves: #7188
|
|
|
|
|
|
- Related: #6359
|
|
The mailing list was linked, but now there is a proper documentation
page.
- Releases: 0.4.0
|
|
Nicknym server is authoritative for its own domain, but for others it might
retrieve keys from key servers. On keys from the same domain we set the
validation level to 'Provider Trust'. For other domains in the email
address we set it to 'Weak Chain' as we don't have info about its source.
Resolves: #6815
Related: #6718
Releases: 0.4.0
|
