From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id i7azA81F92IDCAAAbAwnHQ (envelope-from ) for ; Sat, 13 Aug 2022 08:33:49 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id sGbsAc1F92JRSwEAG6o9tA (envelope-from ) for ; Sat, 13 Aug 2022 08:33:49 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 81BE312B91 for ; Sat, 13 Aug 2022 08:33:48 +0200 (CEST) Received: from localhost ([::1]:60504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oMkiR-0004wY-Bg for larch@yhetil.org; Sat, 13 Aug 2022 02:33:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42622) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMkhi-0004w5-TY for bug-guix@gnu.org; Sat, 13 Aug 2022 02:33:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:41496) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oMkhi-0003OT-L5 for bug-guix@gnu.org; Sat, 13 Aug 2022 02:33:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oMkhi-0006D8-Gw for bug-guix@gnu.org; Sat, 13 Aug 2022 02:33:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#56799: (gnu services configuration) usage of *unspecified* is problematic Resent-From: Maxim Cournoyer Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 13 Aug 2022 06:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56799 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Attila Lendvai Cc: 56799@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 56799-submit@debbugs.gnu.org id=B56799.166037233223817 (code B ref 56799); Sat, 13 Aug 2022 06:33:02 +0000 Received: (at 56799) by debbugs.gnu.org; 13 Aug 2022 06:32:12 +0000 Received: from localhost ([127.0.0.1]:59478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMkgu-0006C5-Aj for submit@debbugs.gnu.org; Sat, 13 Aug 2022 02:32:12 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]:43537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMkgp-0006Bo-79 for 56799@debbugs.gnu.org; Sat, 13 Aug 2022 02:32:10 -0400 Received: by mail-qt1-f170.google.com with SMTP id a4so2261419qto.10 for <56799@debbugs.gnu.org>; Fri, 12 Aug 2022 23:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc; bh=V7BoSjtXC9VJeEROaD87AedI5Na4R1MgnbZ2VuYuajA=; b=c3l6/oEHhfkghJTLWfkEyoBimAMqhAw7zQWhmUFP+7YFGT7WSGiBZ78OAOOVH7AzE5 ZDo7FXexi4+p4qK68IAyvxyotiy3UtT8MHtLJdeKrzeHnLndo5wVVC79FenVafkB4Cwo BVgH2wIB7SsZaMW1fClly0S7VxUpxJgw9d0P615S3olEkvT7FquPdun+bqPBJa7l5mzO pAyH7Pzn9DrzRtCWkWD1zZJiFXh1O79S3ct/tNn4xApx+wI6U4UW3219qFOfIiBnHpFw XBZ+zqjr9qsF647WdJ/sXz9R0ZR5GDIyEyE2r6IYzbGDTcAg8OyUq6XWA0aoy1BZtAVM RbcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=V7BoSjtXC9VJeEROaD87AedI5Na4R1MgnbZ2VuYuajA=; b=a6opDCRzqrZdVVQf+5qVIxbdQrjj6v4Onanfmb9QO1VuLq1KP0la0w/mAQflkyqDig T9KYTbkN5kiShek3/4zauqxzGfVg7isssAqp8jFQJ7TWmn/awceWvBN+KfdglZg6BeOe c74Ny9/3m8Y4xFEKxT+Lv2f3pYKHH5O+t3QVnxyPlrWwOdpxIJDCrx+36FWlzMtEkdQQ W7AmjTMJWfXCjPiLuRW0qc3pOxesIH+AWyW10a4WNlOkxvJbmrgKt7Sj4d5m+GgI9T2U bSulRA2FVPXtKOuBAIcKU7hcH7y3oyP1pkbh99buz4yJlYCBA64CO8IiYvqL6S1kv1db 25hA== X-Gm-Message-State: ACgBeo1s3Q7qn7/P4D9NOMUrTV5SYJJ0zJgF5OOkOZQ5mWbCbFm0PygR l82Nh2GWSDoWkP/tdfqWGeklUbwJjwc= X-Google-Smtp-Source: AA6agR5gpPPCP7CBjK98PLSLy+1+4+rGI6iLF8V6DZfR9in3BgB6p2B24WQzJoAqwY5KwztleJi7vA== X-Received: by 2002:a05:622a:43:b0:343:7b9d:7f31 with SMTP id y3-20020a05622a004300b003437b9d7f31mr3888995qtw.521.1660372321161; Fri, 12 Aug 2022 23:32:01 -0700 (PDT) Received: from hurd (dsl-205-233-125-72.b2b2c.ca. [205.233.125.72]) by smtp.gmail.com with ESMTPSA id dt34-20020a05620a47a200b006b9815a05easm3648782qkb.26.2022.08.12.23.31.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Aug 2022 23:32:00 -0700 (PDT) From: Maxim Cournoyer References: <87o7xa8qxt.fsf@gmail.com> <8735egxedv.fsf@gnu.org> <87les82c2f.fsf@gmail.com> <87v8rbumnx.fsf@gnu.org> <87sfme1y8m.fsf@gmail.com> <877d3omc9c.fsf@gnu.org> <878rnwn5i4.fsf@gmail.com> Date: Sat, 13 Aug 2022 02:31:59 -0400 In-Reply-To: (Attila Lendvai's message of "Thu, 11 Aug 2022 10:15:43 +0000") Message-ID: <87ilmwd57k.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1660372428; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=V7BoSjtXC9VJeEROaD87AedI5Na4R1MgnbZ2VuYuajA=; b=I7oQvK9SA7V0j8nBlMA3/7IPGP+b3nnEUwgiEE5G/jvNoRkZA1WxXPz+PyMHuzr6gJDmAm T5duoResTsP70hHKNupZ1Bh+JYSY2v40xjGF9okTNNAFqtzSg2Hac1wyMLPbKY3Ht9pM9m Q/7WXO0z0HMS5Jjw2qXE+IAu5ElYdvjrPBmKB4tX9DFY3SUDLk77aixy0xYzoffbKToXjg gdG1tr2b2nb2vbZv/4hyRnvqRQa8UfsDvAUx1v1pqMwY8tXnPe/ua2IQ99Jbg8flrsm3Fl LZm8gZUV2fmMEDG7DWWfNn99dU1r2lRVLjqlyGZSJTgaQ75Nzyj8N2h31drhpg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1660372428; a=rsa-sha256; cv=none; b=ni2LRWtuHA4FLbX3cOroQnjrzEFKKt4Uf5+4KYriXCvLLPU+0cMPTWtopz7Qb5HaILMU1k 6ESFWrJwUm09RQEz7n7bsqdsy/hEaVuMp79iXhh0UW7lws4ZPX3s4qupmO//croW1PUbAx eT9VEuTJwQb0Wg8LluL7J6dwuJZtQs+YBWeEWCimO1Iz0cwPVL53obulZ3on33vj9mqGsI 5FBJY6YVy0CpFl4LPJZy3E18Z8Kctg/oePm42vvP9jBIOy2rzfpXuxMPbJ3zplOBaeC7gD CI74JtqcPvtvn6Fqcq/h8N2IfCmmCNdcTS/pHw08xDw2JjhAMDBl74lfEltS0w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="c3l6/oEH"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 6.84 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b="c3l6/oEH"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 81BE312B91 X-Spam-Score: 6.84 X-Migadu-Scanner: scn0.migadu.com X-TUID: Ej7b4hzd+Wbv Hi Attila! Attila Lendvai writes: >> OK, I've reread this, and it is indeed a risk, that 'unset could leak in >> the case of a serializable configuration making use of a maybe-value >> field of type maybe-symbol. I've added the unit test suggested as >> 97cb43e732a38758c95b7caf3963507188d011cf (currently marked as 'expected >> to fail'). Luckily no current service uses that. > > thank you for that Maxim! > > and sorry for my initial, somewhat reactive, and emotionally driven > response earlier! maintaining a channel with complex services, and > finally getting the changes i needed merged into Guix proper was a > source of frustration for me. No worries. We all get caught in emotions at times. It's not necessarily a bad thing, it's a sign we are invested and care. > i've looked at the current state of the code, and it looks good to me. the only issues i have left are the following: > > 1) the (eq 'unset ...) scattered around the code; it should be hidden > behind an explicit abstraction, but you yourself mentioned this > already in an earlier mail. i'd call it CONFIGURATION-FIELD-SET? > (instead of MAYBE-SET?). it's longer, but we have completion in emacs, > and it won't be used a gazillion times all around the code either. I had used maybe-value-set? because the maybe values are define via the 'define-maybe' syntax; they are not really part of 'define-configuration' and are sometimes used outside of it, such as in (guix home ssh). > 2) the lack of an abstraction for the unset/unspecified > value. whatever we use as the marker should be hidden behind either an > exported global variable, or a function called > UNSET-CONFIGURATION-FIELD! (or something alike). i should have > introduced these myself, and then your fix would have been as simple > as replacing *UNSPECIFIED* with 'UNSET in the abstraction. An exported variable seems simplest and perhaps less awkward to use, e.g. %unset or similar, although it's a bit ugly that we need to reify an unspecified value :-). > 3) the SYMBOL? corner case that your test captures, but it's not a burning issue for me (it doesn't affect the user facing API, once the above leakages are fixed). > > do you agree? if yes, will you implement it, or shall i prepare a patch? I sent a patch somewhere for the maybe-value-set?, see message-id <87bkstnd2d.fsf@gmail.com> up this thread. I'd be happy if you could prepare a patch for the other things mentionned here (an exported symbol). > one more note: sometimes it's useful to have a field with a maybe type > that also has a default, together with the ability to explicitly unset > this field. True. I'd prefer if this never was true for simplicity (a maybe field would not need to take a default value), but the reality is that we may want to set a sane default value while allowing the user to clear the field to have the software use its default behavior. > > an example would be a port specification for a torrent client: it has some default port, but it's possible to explicitly unset the port value to request the allocation of a random port at startup. > > to better accommodate for this use case, 2) should probably be > implemented not as an UNSET-FOO! function, but as a global variable > holding the unset value marker. or maybe both? I'd keep things simple with the exported unspecified value rather than both. A single, obvious way to do things is simpler. Thanks, Maxim