Antoine Beaupré | 19 Mar 04:06 2015

Re: monkeysign.gpg: --always-trust when signing a key

On 2015-02-21 11:07:17, Daniel Kahn Gillmor wrote:
> Hi Tobias--
>
> Thanks for raising this issue!
>
> On Sat 2015-02-21 10:02:04 -0500, Tobias Mueller wrote:
>> This is to overcome a problem with GnuPG.  It will print
>> "gpg: checking the trustdb" on stderr after a key has been signed.
>>
>> The alternative here is to call --check-trustdb.   I think that's more
>> expensive though. And probably not necessary, anyway. We have already
>> decided that we do want to sign the key in question.
>>
>> Another possibility is to allow certain lines when calling expect().
>> It may be worth it, but the current solution seems to be less invasive.
>
> --always-trust is a mode that radically changes the semantics of GnuPG's
> trust model (and therefore its interpretation of the keyring).  For a
> tool that is specifically designed to interact with the GnuPG trust
> model, setting --always-trust sounds dangerous to me.

why exactly?

a.
--

-- 
It is the greatest of all mistakes to do nothing because you can only
do little. Do what you can.
                         - Sydney Smith

(Continue reading)

Antoine Beaupré | 19 Mar 04:05 2015

Re: monkeysign.gpg: --always-trust when signing a key

On 2015-02-21 10:02:04, Tobias Mueller wrote:
> Hi.
>
> This fixes a bug when signing a key with more than one secret key.

i am unclear as to why this is necessary. like CAFF, monkeysign uses
"--trust-model always". in which cases do you see this happening? how
can you actually sign with more than one secret key?

i tried to fix it up so that doesn't do the silly check-trustdb as well
in the dev/trustdb branch, but this went nowhere.

maybe --always-trust is what we need here. did you try
"--no-auto-check-trustdb --trust-model=always"? it's what CAFF actually
uses.

a.

--

-- 
If you have come here to help me, you are wasting our time.
But if you have come because your liberation is bound up with mine, then
let us work together.    - Aboriginal activists group, Queensland, 1970s

Antoine Beaupré | 19 Mar 03:57 2015

Re: monkeysign.gpg: Give the OpenPGPKey and UID a __repr__

On 2015-02-21 08:42:50, Tobias Mueller wrote:
> Hi.
>
> With this simple cosmetic changes I find it easier to work with the gpg
> module.

makes sense, merged in 2.x.

please be careful with trailing whitespace: most patches you sent had
warnings from git...

a.
--

-- 
In a world where Henry Kissinger wins the Nobel Peace Prize,
there is no need for satire.
                        - Tom Lehrer

Antoine Beaupré | 19 Mar 03:55 2015

Re: monkeysign: GnuPG 2.1 compatibility

On 2015-02-16 12:15:35, Tobias Mueller wrote:
> diff --git a/monkeysign/gpg.py b/monkeysign/gpg.py
> index 9b09536..4417b21 100644
> --- a/monkeysign/gpg.py
> +++ b/monkeysign/gpg.py
>  <at>  <at>  -586,30 +586,82  <at>  <at>  class OpenPGPkey():
>              elif rectype == 'fpr':
>                  self.fpr = record[9]
>              elif rectype == 'pub':
> -                (null, self.trust, self.length, self.algo, keyid, self.creation, self.expiry, serial, trust, uid,
sigclass, purpose, smime) = record
> +                self.trust = record[1]
> +                self.length = record[2]
[...]

thanks for the patch, but I believe a more pythonic way of doing this
would be:

> -                (null, self.trust, self.length, self.algo, keyid, self.creation, self.expiry, serial, trust, uid,
sigclass, purpose, smime) = record
> +                (null, self.trust, self.length, self.algo, keyid, self.creation, self.expiry, serial, trust, uid,
sigclass, purpose, smime) = record[:12]

or something similar.

a.

--

-- 
Perl is "some assembly required". Python is "batteries included". PHP
is "kitchen sink, but it’s from Canada and both faucets are labeled C".
(Continue reading)

Antoine Beaupré | 19 Mar 03:46 2015

Re: Monkeysign: Detect key revocation

On 2015-02-16 12:05:20, Daniel Kahn Gillmor wrote:
> On Mon 2015-02-16 08:20:25 -0500, Tobias Mueller wrote:
>> On Mon, Feb 16, 2015 at 02:14:09PM +0100, Kristian Fiskerstrand wrote:
>>> On 02/16/2015 02:09 PM, Tobias Mueller wrote:
>>> > As a fun fact:  GnuPG does not seem to export that information when
>>> > doing a --list-keys --with-colons.
>>> 
>>> revoked keys should have a "r" as field 2 c.f. DETAILS. I've not
>>> encountered this not working in operations.
>> sorry, I meant --list-secret-keys, which is what we're interested in.
>
> fwiw, the "r" shows up in field 2 of the --with-colons
> --list-secret-keys output when using gpg 2.1.  I know this doesn't solve
> all of our problems, but i think it suggests that the proposed fixes
> here are actually workarounds, and should maybe be conditional on the
> version of gpg used.

we do not currently go around guessing what version of gpg we are
using. instead we assume the lowest common denominator that i could get
my hands on (wheezy, in my case).

a.

--

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality.         - Ursula Le Guin
(Continue reading)

Antoine Beaupré | 19 Mar 03:53 2015

Re: Monkeysign: Detect key revocation

On 2015-02-16 08:14:09, Kristian Fiskerstrand wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 02/16/2015 02:09 PM, Tobias Mueller wrote:
>> Hi.
>> 
>> I've implemented the detection of revoked keys.
>> 
>> As a fun fact:  GnuPG does not seem to export that information when
>> doing a --list-keys --with-colons.
>
> revoked keys should have a "r" as field 2 c.f. DETAILS. I've not
> encountered this not working in operations.
>
> also, options before commands, so correct order is --with-colons
> - --list-keys (although both will work in this specific case)

I have pushed tobi's patches for this on the 'dev/revoked' branch,
because I agree this should probably be done in the right order.

Tobi, I also disregarded the 'expiry' patch you seem to have included in
that mail - i merged it in 2.x directly.

Can you make a patch on top of the stack to fix the above?

A.
--

-- 
Thousands of candles can be lit from a single candle
And the life of the candle will not be shortened.
(Continue reading)

Antoine Beaupré | 19 Mar 03:45 2015

Re: Monkeysign: Calculate key expiry

On 2015-02-16 06:45:09, Tobias Mueller wrote:
> Hi.
>
> Actually, scratch the version I sent. This version works now.
> I've tested it now.  The monkeyscan UI now does not show expired
> keys in the "identity" menu anymore.

Thanks, that's great! I merged it in 2.x.

> FWIW: One could think of parse_gpg_list already providing a datetime
> object rather than us having to recreate that on every access.

Yes, that would seem reasonable.

A.
--

-- 
Ce que les siècles des grands abatoirs nous aura appris
Devrait être inscrit au fond de toutes les écoles;
Voici l'homme: le destructeur des mondes est arrivé.
                        - [no one is innocent]

Sebastian Lipp | 22 Mar 00:07 2015
Picon

Re: Locked out due to key expiration (?)

Sebastian Lipp <bacuh <at> riseup.net> writes:
> Hey there!
>
> My server('s monkeysphere) stopped recognizing me so I'm absolutely
> screwed and now hope you can help me recover.
>
> I believe the most likely cause of the problem is a recent expiration of
> my subkey which I replaced by a new one. See my key F847A316 for
> reference.
>
> Attached is a slightly shortened log of a attempt to connect. Any idea
> how I may proceed from here?

I finally got some hours to get me back onto said server. I was then
able to solve my problem by executing add-identity-certifier.

Thanks for your help some weeks ago.
basti

--

-- 
react!OR               ::         Frühlingstr. 17 | 87439 Kempten
selbstverwaltetes JuZe :: Infoladen | Umsonstladen | Offener Raum
https://react.or.ke    ::                  Telefon: 0831 52623689

Der react!OR lebt von Dingen, die anderswo übrig sind. Aktuell gesucht:
Kamera, Prospektständer, Fahrradanhängerkupplung, Werkzeug, USB-Sticks,
Speicherkarten, Computermäuse, ... mehr: <https://react.or.ke/suche>

fr33domlover | 30 Apr 00:21 2014
Picon

Usage with mail server

Hello,

This is my first post here. I run an SSH server and a web server and I'm
very interested in using a peer-to-peer decentralized natural way to
handle trust.

Moneysphere already works with HTTPS and SSH as described in your
website, but I didn't find any information about:

- XMPP server (as far as I know, none exists yet but it's WIP)
- mail server

I'm going to run a mail server (first just IMAP, later I'll add SMTP)
and I'd like to not use an SSL certificate from a centralized source
which requires a lot of my private information for spying me and
verifying my identity etc.

Does moneysphere support mail serving?

I can imagine it may work for sending mail to the user, but what happens
if an SMTP server wants to send email to my IMAP server? How does the
SMTP server send me encrypted data if it cannot recognize my OpenPGP
based "certificate"?

If there's any approach waiting to be implemented or used, I don't mind
pioneering. Just tell me please how it works. Also, maybe I can help add
monkeysphere support to dovecot if it's not too difficult.

Thanks in advance!
Sincerely,
(Continue reading)

micah | 21 Apr 01:41 2014
Picon

Re: Archlinux Package

Profpatsch <mail <at> profpatsch.de> writes:

> On 14-04-10 06:21pm, Profpatsch wrote:
>> Since you are linking to a git package which is broken atm:
>> 
>> There is a package using the official releases at
>> https://aur.archlinux.org/packages/monkeysign/
>
> And I just became maintainer, so it’s up-to-date now, too.

If you would like to update the link on the page, the site is running
ikiwiki, a patch or a git remote would make the update real easy!

Gabriel Pérez-Cerezo | 30 Mar 13:23 2014
Picon

Monkeysphere integration in Links2

Hello,

I have changed my plans. I have stopped working on w3m and now I'm working on Links2,
as it has much more features and is more widely used. I will write you when it is
ready.

Best wishes,
Gabriel

--

-- 
Gabriel Pérez-Cerezo Flohr
Website: http://gpcf.eu  E-mail: gabriel <at> gpcf.eu
GPG Key: D353EC69 (get it from http://gpcf.eu/key.asc)


Gmane