From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id aOK5N4jrvl9TOQAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 23:40:56 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id oHeHM4jrvl+rBQAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 23:40:56 +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 4FCA59400BF for ; Wed, 25 Nov 2020 23:40:56 +0000 (UTC) Received: from localhost ([::1]:49562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki4P9-0003oH-A6 for larch@yhetil.org; Wed, 25 Nov 2020 18:40:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki4OL-0003n8-AV for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 18:40:05 -0500 Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:33828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki4OJ-0003fo-EF for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 18:40:05 -0500 Received: by mail-pf1-x42e.google.com with SMTP id w6so3853276pfu.1 for ; Wed, 25 Nov 2020 15:40:03 -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=RPhLYgxD3J9ATj/SnuR6FKuGB3sZUKd3bLr1N5LK81E=; b=PKSDRgk+uyeL4W7troZdZJB0KueYjT8EDEp3LEab5vuX/olyV1UM7UADTNS2lU21WJ S7jigAJk2m1ximXvRULEMvtR2oiwqukhN8G4erR398RSdFeVmxDfpK24Gg90MYn4iZ2o vU7gRcR7fLAeBu8qGQCNgPHC5Yv421oY37akEf+Prrcyd69FT+ZGDRn0dsZzgflZEhqi qlMIXuzZzt7SjcFkfV+ymPLSTEA1DVclcWcp2OOyjBixmRUQAIOWkK4Nus+KyTq5gBb1 1Ci/EEvBayeskW8zNOCvtxZnGSyvU5FSZNyjt+LlBsN7jLBiE0oUfY2e+hkICFmK/ZVf G2kQ== 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=RPhLYgxD3J9ATj/SnuR6FKuGB3sZUKd3bLr1N5LK81E=; b=oFFcuyNm6aSk6RgDCGNRoD1MFxnm4qoKy25WUNQoBswLvB3Oi3HvTbhToFBJLhftaS X6bEYAFxIaPvm9cU/twO+q/ulqat+D1LH9F1UG0ESHUnfp4G6j7SEom1Hwaf5LuQA+Kx XmF98GWW6zfpppjck/yflLuDcirZLhWjd5odpUwfsYqZxKJD/I9oPD7u5O4MltVawk6e Iu1K+MTvmksdP4ktTxI6IM14f55Is4uiD8fD0/OScC2Mrt/cAWs82J46s5DYC/R49Tme 1X6f5KmKupTktLa38L671lpHFIi/IXtz1Jx2aVhMTHCG0N9ON+2ww3VfwcrP7FlBusOc ChuA== X-Gm-Message-State: AOAM531/DYkgxKu0b6b9OTZ11hA2spisI54edNkD1z5p5cr2EjFrpKWe 6KlJ9vx8cOQ+I4AmMP0giKbPu9mZ8l31dw== X-Google-Smtp-Source: ABdhPJz1aLrPKrckzOa3UZbWiRPfEuZMDiMYXZ5nOvXM2DoZZcs9f+sgC9PIPbF60CqztiUNTaOjkw== X-Received: by 2002:a17:90a:fd02:: with SMTP id cv2mr222747pjb.176.1606347601821; Wed, 25 Nov 2020 15:40:01 -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 n2sm2879282pfq.129.2020.11.25.15.39.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Nov 2020 15:40:01 -0800 (PST) References: <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> <875z5uxzev.fsf@gmail.com> <87v9dt7wfa.fsf@gmail.com> <87mtz56omv.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: <87h7pd6m5u.fsf@gmail.com> Date: Thu, 26 Nov 2020 10:39:57 +1100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42e.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-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=PKSDRgk+; 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: omTyh/p2i0nz Jean Louis writes: >> >> this is wrong. In melpa you specify either a commit (SHA) or a branch or >> both. The repository owner has control over this. MELPA doesn't just >> pull data from the repository because there has bene an update. You can >> configure things so that whenever data is committed to a release branch, >> it is pulled, but this is under the control of the repository owner. It >> isn't that different to ELPA where the maintainer will either push new >> data to the ELPA repository (or ask someone with write permission to >> pull it from their repository). > > 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. 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. They can also specify a branch rather than a commit SHA. In this case, MELPA will retrieve updates from that branch, so when that branch is updated, it will pull new data. In this case, it is up to the developer to manage their 'release' branch appropriately. when they are ready for a new release, they push their updates to the release branch and update the version tag. This is pretty much the same as ELPA works for external packages (those which don't manage their code within the GNU ELPA repository itself) > > So is there automatic pulling? > > I compare automatic pulling and building to author's decision on when > a package would be issued. > Your model is flawed. You can have both automatic pulling AND author control over when a new package is issued. 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. 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. MELPA does not automatically generate a new package just because something has changed within the git repository. It has to be a change to a specified branch and update to the version tag or it has to be a change in the recipe with an update to the commit SHA. -- Tim Cross