From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cDJXEMtPv1/KOAAA0tVLHw (envelope-from ) for ; Thu, 26 Nov 2020 06:48:43 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id EC4fDMtPv194cAAA1q6Kng (envelope-from ) for ; Thu, 26 Nov 2020 06:48:43 +0000 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 744C994042C for ; Thu, 26 Nov 2020 06:48:42 +0000 (UTC) Received: from localhost ([::1]:42556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiB55-0004j0-Qo for larch@yhetil.org; Thu, 26 Nov 2020 01:48:39 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38004) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiB3O-0004ia-MA for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 01:46:54 -0500 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]:35175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kiB3I-0000vJ-Mm for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 01:46:54 -0500 Received: by mail-pg1-x52e.google.com with SMTP id k11so914319pgq.2 for ; Wed, 25 Nov 2020 22:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version; bh=EMRSNg+RDZnChTA0xFa6jEK1C44dNDKRsh+MVOfbrXs=; b=pzw1U/5zOQeSsmJpQfpitMf7XfU4WkDQhqovsT53GgaUBdwN/3q9GpAOcIA5cHE59t tbKX+c8qbfsTPVBcIokhWKJafW1/ZdQrDlm4IdeHpGIyLx45RO5uZyk2q0Zq7QCOgGv5 x8aiA/F9mhPgF63w06ISP9+uWxOwChWkKiiAAs3SfKAFg6A980N+Tpu+63ijGNODo3ND OIWHfx6AOvQDe7RvfmBw1592VELkw48WbPulwqkmcbxMjzrxlxcEtxqIH9PO3SBE+VCy XPwCzmNMXMYVui0PuWpvhD4vNOqY8A1Y8EsYvSbL5Me1W1oKMIQls2zKP7Ve+ZmOzvGy 46sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=EMRSNg+RDZnChTA0xFa6jEK1C44dNDKRsh+MVOfbrXs=; b=c5YHiktB7XQG3ORXDm/A9/sv8DOcZzg8r/tYoy4BuF88CcIgeXCQZQCBRUy9y8MVpM 2LakNIRLCO5B8kT+OIPUpYgtWiTXmc8TZoMvsNXsXY9Wd2ywFmxK11qP+kOpqRRVoTPy RwTj/pCq967GXXO0kxzvTnv4y7lBGtIc0t6gT/AauNfQhbEUghRKLKtJcjZmNHuWAOeR yaaqfm2rvinUJbQugCUzLhNm/ZTIiVv1mPmcuBVVGx1vu8QeRQ2MB4R0h5nO4BSwZcZ2 0QEbLTS13S3kLgz3MSkXf45JjbRQ49Q8emVgQNHGmtiFyKNbA+NCBxfFAHwZiAKILfTK Ku7w== X-Gm-Message-State: AOAM530ltIxaD/X3sJiXNSBxK/OLxLZ3nlDf2UtGXPmAT9dieRg2QaE1 RaPCFaukGHJaFKq2flRAYpEY4eLKs5v6jQ== X-Google-Smtp-Source: ABdhPJwJ5UknUqXIV4JSOBMGDrRztsEdPd34h3rRKwTaXKy9bEzapqaVl+ScYItYAAQuQiY0pIoTXQ== X-Received: by 2002:a63:784:: with SMTP id 126mr1444234pgh.215.1606373207002; Wed, 25 Nov 2020 22:46:47 -0800 (PST) Received: from tim-desktop (106-69-100-122.dyn.iinet.net.au. [106.69.100.122]) by smtp.gmail.com with ESMTPSA id q18sm3723694pfs.150.2020.11.25.22.46.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Nov 2020 22:46:46 -0800 (PST) References: <87zh36d1xn.fsf@web.de> <875z5uxzev.fsf@gmail.com> <87v9dt7wfa.fsf@gmail.com> <87mtz56omv.fsf@gmail.com> <87h7pd6m5u.fsf@gmail.com> User-agent: mu4e 1.5.7; emacs 27.1.50 From: Tim Cross To: Jean Louis Subject: Re: Security issues in Emacs packages In-reply-to: Message-ID: <87360w62ek.fsf@gmail.com> Date: Thu, 26 Nov 2020 17:46:43 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::52e; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: inc X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=pzw1U/5z; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: 8zShVUANMbpF Jean Louis writes: > * Tim Cross [2020-11-26 02:40]: >> > OK it is great that it is so. Are you maybe author doing it? Is there >> > any reference that authors are doing so? I have MELPA downloaded you >> > could tell me how do I see that author is deciding if package is for >> > release? >> > >> >> You can clone the melpa repository and see the recipes for each >> package. > > I did before some time. > >> It depends on how the author specifies their MELPA recipe. They can >> define their recipe based on a specific commit (SHA). If they do this, >> it doesn't matter how often or when MELPA pulls from the repository as >> they will always get the same commit. > > I have not seen that, and I have assumed you would know better and > wanted to see how authors are reporting that package is ready for > release and I do not see that. > > Recipes are like this: > > (0blayout :repo "etu/0blayout-mode" :fetcher github) > > (0x0 :url "https://git.sr.ht/~zge/nullpointer-emacs" :fetcher git) > > (0xc :fetcher github :repo "AdamNiederer/0xc") > > So that recipe alone does not tell me that author reports that new > package is ready, it is fetched from git, but there are parts of code > that I did not see that is why I am assuming you know it better. > >> Your model is flawed. You can have both automatic pulling AND author >> control over when a new package is issued. > > To make it practical tell me where is that author's control? > > I have quick view of files and any recipe files in directory > melpa/recipes do not give me any pointers, it is all automated and > fetched from git. > >> If author defines their MELPA recipe to use a SHA a new package will not >> be issued until they update their recipe with a new SHA. > > You seem to be very confident and for this reason I assume you know it > better, but due to contradictions please show one practical recipe or > package where author has control on when is package ready to be > released. > > $ grep sha * > > on recipes does not give any reference. > > $ grep commit * > > eval-in-repl: :commit "origin/master") > git-auto-commit-mode:(git-auto-commit-mode :fetcher github :repo "ryuslash/git-auto-commit-mode") > git-commit:(git-commit :fetcher github > git-commit: :files ("lisp/git-commit.el") > git-commit: :old-names (git-commit-mode)) > git-commit-insert-issue:(git-commit-insert-issue :fetcher gitlab :repo "emacs-stuff/git-commit-insert-issue") > vc-auto-commit:(vc-auto-commit :fetcher github :repo "thisirs/vc-auto-commit") > what-the-commit:(what-the-commit :fetcher github > what-the-commit: :repo "danielbarbarito/what-the-commit.el") > > So there is nothing I can find that points or references to what you > say. > >> If author defines their MELPA recipe to pull from a release branch, a >> new package will not be issued until they update the release branch and >> version tag. > > I am sorry I do not see reference to it. You are convincing but I do > not see reference. > > Recipe for bar-cursor: > (bar-cursor :repo "ajsquared/bar-cursor" > :fetcher github) > > Recipe for magit: > > (magit :fetcher github > :repo "magit/magit" > :files ("lisp/magit" > "lisp/magit*.el" > "lisp/git-rebase.el" > "Documentation/magit.texi" > "Documentation/AUTHORS.md" > "LICENSE" > (:exclude "lisp/magit-libgit.el" > ;; Cannot remove this yet because it would > ;; also be removed from the stable version. > ;; "lisp/magit-section.el" > ))) > > Repo magit/magit: > https://github.com/magit/magit > > I have given you references, maybe I cannot read that well, so you can > give me references to show if authors have participation in decision. > The available recipe options are all clearly documented in the README for the melpa repository. Most maintainers don't use the :commit option because it is extremely inconvenient, but it is there if they want it. It is inconvenient because it means the recipe has to be updated, which means a pull request has to be accepted before the package can be released. Most maintainers will maintain a specific branch for releases. This is normal practice in version control. Often, this is the master branch, but 'release' and 'melpa' are also commonly used. Code is not pushed onto these branches until it is ready for release. The package maintainer has full control of this branch and therefore has full control over when new code is released. This is also the model used by GNU ELPA for external packages. This is not the model you imply, where MELPA just grabs the data whenever it wants and releases new version without management by the package maintainer, resulting in the release of code that is not ready for release. -- Tim Cross