monkeysign issueshttps://0xacab.org/monkeysphere/monkeysign/-/issues2018-02-15T09:52:05Zhttps://0xacab.org/monkeysphere/monkeysign/-/issues/16don't use popups2018-02-15T09:52:05ZJerome Charaouidon't use popups*Imported from bugseverywhere, created on 2013-10-20**Imported from bugseverywhere, created on 2013-10-20*Monkeysign 3.0.0https://0xacab.org/monkeysphere/monkeysign/-/issues/15wrap labels dynamically2018-02-15T09:52:05ZJerome Charaouiwrap labels dynamically*Imported from bugseverywhere, created on 2013-10-20**Imported from bugseverywhere, created on 2013-10-20*Monkeysign 3.0.0https://0xacab.org/monkeysphere/monkeysign/-/issues/13Switch from qrencode to qrcode2018-02-15T09:52:05ZJerome CharaouiSwitch from qrencode to qrcode*Imported from bugseverywhere, created on 2013-12-07*
we currently use the [qrencode](https://pypi.python.org/pypi/qrencode) library to generate qrcodes. that library is pretty simple and wraps around the C qrencode library, but we ha...*Imported from bugseverywhere, created on 2013-12-07*
we currently use the [qrencode](https://pypi.python.org/pypi/qrencode) library to generate qrcodes. that library is pretty simple and wraps around the C qrencode library, but we have had problems with it before:
* [needed to be ported to the new PIL interface](https://github.com/Arachnid/pyqrencode/pull/8) (fixed)
* [last release took two years to fix the above](https://github.com/Arachnid/pyqrencode/issues/5)
[qrcode](https://pypi.python.org/pypi/qrcode) is a pure-python library that also installs a `qr` command that can be used to test the library standalone. furthermore, it seems to be a little better maintained.
porting should be trivial, but we should check if both libraries are as well supported everywhere first.https://0xacab.org/monkeysphere/monkeysign/-/issues/11allow --cert-notation2018-02-15T09:52:05ZJerome Charaouiallow --cert-notation*Imported from bugseverywhere, created on 2014-02-04**Imported from bugseverywhere, created on 2014-02-04*https://0xacab.org/monkeysphere/monkeysign/-/issues/6consider local key exchange mechanisms (geysigning, safeslinger)2018-02-15T09:52:05Zanarcatconsider local key exchange mechanisms (geysigning, safeslinger)The [geysigning project](https://github.com/muelli/geysigning), which reuses (and improves on!) parts of the Monkeysign code, introduces a novel idea of *not* depending on the keyservers to fetch the public key material before signing. T...The [geysigning project](https://github.com/muelli/geysigning), which reuses (and improves on!) parts of the Monkeysign code, introduces a novel idea of *not* depending on the keyservers to fetch the public key material before signing. To quote their README file:
> In contrast to caff or monkeysign, this tool enables you to sign a key without contacting a key server. It downloads an authenticated copy of the key from the other party. For now, the key is authenticated by its fingerprint which is securely transferred via a QR code. Alternatively, the user may type the fingerprint manually, assuming that it has been transferred securely via the audible channel.
I haven't figured out exactly *how* the key material is copied - it is presumably done through some Avahi protocol?
OpenKeychain has its own way of doing those transfers, which are implemented as a multi-party "keysigning party" protocol of some sort. It uses an app called [SafeSligner](https://www.cylab.cmu.edu/safeslinger/) for which there is a [Python library](https://github.com/SafeSlingerProject/exchange-python-web) we could reuse as well.
List of possible implementations:
* [geysigning][geysigning project] - homegrown avahi + httpserver
* [SafeSlinger][] - custom protocol?
* [FlyWeb](https://flyweb.github.io/posts/2016/11/01/introducing-flyweb.html) - standardized web-based avahi + httpserver?Monkeysign 3.0.0https://0xacab.org/monkeysphere/monkeysign/-/issues/3continuous integration2018-02-15T09:52:05Zanarcatcontinuous integrationit would be nice to make sure tests pass when pull requests are set here... there are other things that could be ran to make sure code that is merged improves the project, and or at leat doesn't make it worse. :)
* [ ] configure a mac...it would be nice to make sure tests pass when pull requests are set here... there are other things that could be ran to make sure code that is merged improves the project, and or at leat doesn't make it worse. :)
* [ ] configure a machine to run tests, the `gitlab-ci-multi-runner` debian package, apparently simple enough to setup and use (on `george.riseup.net`?)
* [ ] configure tests to be ran in ` .gitlab-ci.yml`
* [x] unit tests (`./test.py`, may need improvement?)
* [ ] style checks with [flake8](https://pypi.python.org/pypi/flake8)
* [ ] test coverage (with [coverage](https://coverage.readthedocs.io/en/coverage-4.2/)?)
* [ ] security checks (with [bandit](https://github.com/openstack/bandit)?)
* [ ] anything else?
* [ ] enable "builds" and hook everything up