Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]

Wiktor Kwapisiewicz <> Tue, 12 January 2021 09:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D5E33A0EA8 for <>; Tue, 12 Jan 2021 01:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 346GeRng4z-a for <>; Tue, 12 Jan 2021 01:48:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AB3F3A0EA0 for <>; Tue, 12 Jan 2021 01:48:06 -0800 (PST)
Received: by with SMTP id i9so1768361wrc.4 for <>; Tue, 12 Jan 2021 01:48:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2017; h=to:references:from:organization:cc:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UZJHCkEhFCDDTj4VhlXL4asWM0wKlKZKLXPkup4ux1M=; b=IrTDlmXsTypkgPvH8SqsSndwBa3Ea0Vaq6RhfBszcY3DeqVrMbyMeA3/5m/BiHveze XNCgVWIIkKM9O+Y8RdcCkvi/6fIeImjqRx8lhOuUfn3Ttg+75GzDWTu+u1Udun0BeQp7 I0uffzWAzSzR+wCg2JEllF+iW/SUexNf2Ay0OnmH0e39KOXJnBMCmIg8vpPK9MlWfNQZ ZGdFbLOShv38V8WPKJ4bwdFApcWfowGjMKL7clMduWhfc0T1IjPRxiZJCuIZunfyUZri BPs6u08gmabDUpZiJtOhinQlY4gsFjKCpFFVDQDKCsZGjVDouizJ7kAbWkgQlaGRMY4q TnPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:to:references:from:organization:cc:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UZJHCkEhFCDDTj4VhlXL4asWM0wKlKZKLXPkup4ux1M=; b=q8Synxubu99i3PQ4MKPkbrac26ovUZVAKkVVTSao+OaBI9ikdpq57nInXjY5hmOEti BGlouZgccSkFJrKb6geLRQhYhDtpJDFe+QOUI35+MubSfrfpujhP7U+GUqBYji2/y9av BTwFKXSCLkutnqxm9Z0imJ/oxYD+XhMvldZvPREVFFmHVo3ovH9ihYf1qgNyownI7taJ +g5DrynScIou1YpStKHrR10OvKDbf3Lse1CJLiIEeMYXYcVZDyHKTGWsF0+t3J9VFduX ulvgdDcUy9KUU9GBuWGkNpv21+AOQiYYYtNp7gEErVJdmYs4Khu7HPx+SHM51EQvAyl6 e2hw==
X-Gm-Message-State: AOAM5305NikmAd4bULqQoQ9VDxuVhEls9kNXPqL0cbLp6aG2w97ALKC7 PiEl8TlbLtQ69ynnjrWWqVR58YFbM/p7TA==
X-Google-Smtp-Source: ABdhPJwNltYRQngzizPQdoeg+5W6Z1tRSKrLEgnPYkm4sWEEvcKBOhcFNzbjzn+gcZrTHSOhoB1juA==
X-Received: by 2002:adf:efc5:: with SMTP id i5mr3210814wrp.377.1610444884271; Tue, 12 Jan 2021 01:48:04 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g192sm2992422wme.48.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jan 2021 01:48:03 -0800 (PST)
To: Ángel <>
References: <> <> <> <> <> <> <> <>
From: Wiktor Kwapisiewicz <>
Organization: Metacode
Message-ID: <>
Date: Tue, 12 Jan 2021 10:48:10 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jan 2021 09:48:08 -0000

Hi Ángel,

On 09.01.2021 01:08, Ángel wrote:
> If a new "Globbing expression" subpacket was added, allowing user ids
> covering any of them would be a simple solution (and probably cleaner
> as well) to not require that {}

If a new subpacket was added I think it'd make sense to store the entire 
expression in a binary (tree) form. This way parsing would be more 
consistent across implementations.

Using regexps invites implementers to just reuse whatever regexp library 
their language has thus inviting incompatibilities.

Of course this is not of highest priority but having a binary packet 
encoding that stores a regexp string that should be parsed with a 
different parser looks like a design issue with the protocol.

Kind regards,