From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 99EFF28BC6 for ; Sat, 5 Oct 2024 15:03:51 +0200 (CEST) Received: from chrisfroeschl.de ([185.183.157.17]) by 9front; Sat Oct 5 09:00:03 -0400 2024 Message-ID: Date: Sat, 05 Oct 2024 15:00:01 +0200 From: chris@chrisfroeschl.de To: 9front@9front.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: leveraged service AJAX over SVG framework standard injection manager Subject: [9front] marshal(1) and pgp Reply-To: 9front@9front.org Precedence: bulk marshal(1) advertises the -pe and -ps flags to encrypt/sign the input. The flags are indeed implemented (/sys/src/cmd/upas/marshal/marshal.c:389) using a /bin/pgp (/sys/src/cmd/upas/marshal/marshal.c:1171) . Does anyone know what this pgp exec is? Some historic relict? I'm only aware of moody's https://github.com/majiru/pgp . I see three options: 1. Remove those flags since there is no real standard pgp 2. Define/Ship a standard pgp for 9front 3. Move pgp logic into it's own more independent component to be piped or offered through the mail client (like an extra nedmail option or something like that) (a better architecture?) I would work out a patch if an appropiate solution is found. I'm currently using moodys pgp with a patched marshal. Regarding 2., I don't think that the golang pgp implemenation would really fit into the 9front release, since this would be the first golang project to be part of the standard build. Feel free to comment. chris