From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Mon, 10 Oct 2022 08:36:50 +1100 Message-ID: <86sfjw7ft8.fsf@gmail.com> References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <871qris3xb.fsf@gnus.org> <86y1tqb0bs.fsf@gmail.com> <87mta52mul.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18339"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.0; emacs 29.0.50 Cc: Lars Ingebrigtsen , Stefan Monnier , emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 10 01:12:53 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ohfTZ-0004Yd-3l for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Oct 2022 01:12:53 +0200 Original-Received: from localhost ([::1]:34504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ohfTX-0006TO-Sx for ged-emacs-devel@m.gmane-mx.org; Sun, 09 Oct 2022 19:12:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ohfSo-0005mB-Bq for emacs-devel@gnu.org; Sun, 09 Oct 2022 19:12:06 -0400 Original-Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]:54958) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ohfSd-0006ce-4Y for emacs-devel@gnu.org; Sun, 09 Oct 2022 19:11:57 -0400 Original-Received: by mail-pj1-x102f.google.com with SMTP id 70so8500880pjo.4 for ; Sun, 09 Oct 2022 16:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=Lg//U3Hxaoa9hf0O8UcGnJs+l8lFVMLVdVhJ5Ic1mPU=; b=PraQo5dKvSSH7fYMKZkcVFTkuV8AS07SeZY6463tR8mWVaHYITu2zMqOfr5ZMB3FzT sN5wp39NX/6LNe/i3DkIoQ0M1ihy8yfepMIzk+2TRa0PPg+MTYHQs11YjNYNZvzDIVIH 2hp8k7KXRuj7GhPgap8Mf1hhxoVOvGSriEEdZAzvhdMJ4mCO1WyCM85S3B0FgsY7odyK D0/brfguUinhgd3IkOqsDylS78Q/HUEAZ6bI+iQ/wR6OcqGPjS4oKcjSc6VZaCtRwPQp y1Wo8aBcR7LSZ6nAll8+3S9RDkI5pzkd7VH+FkfaH3YLdtKLQX9hCVSQNbVYD5fKCdvV 3Lxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Lg//U3Hxaoa9hf0O8UcGnJs+l8lFVMLVdVhJ5Ic1mPU=; b=A9+vfyjx8xEV4CwevUKv4f2ZVb59Tc2bkLpfDYAfi8PX5UU1T526g3mLeuzLY40KnB b9qy81vDOr6lv7MQSfPFNPUqFi+EyAkprHUfloe+vanhSEb8CbuJBhleiAIhRji9HCX7 ZidoYKETwrQe1UjCPqCkRZrW1sNvwP/3S6ZfKeYMENQcM54Pyh3ke06xkQmtpXadlsaQ D6U/kLp3/BB1fNLHvzIa5JbeSm+hNve9JhZJH9F9hswxu+/AoCwBiNfDFKuuN17y/xI3 LSeLr3tWbvYAOoY8yY5+sJq1gm4iXh9ljVm0P+qo7F2BhvSbgD2EdV2EBhNHm9Ups7yp LY/w== X-Gm-Message-State: ACrzQf3fCUi8yaIHSJDzMzKOoFjpzYMSpl1VcXQqsTh57jMlppwHrWoT QSDOpkP6dwS4gcIIk3MZNNvcTYWSdrA= X-Google-Smtp-Source: AMsMyM4QY9YyJq7+92fmWFN+sUwMgMeJ7zUUgJ7qwEnFwusrxdnqio+dUUSc0ZBIUysduNPjePhO3A== X-Received: by 2002:a17:903:509:b0:179:ffcf:d275 with SMTP id jn9-20020a170903050900b00179ffcfd275mr16015935plb.150.1665357113371; Sun, 09 Oct 2022 16:11:53 -0700 (PDT) Original-Received: from dingbat (124-169-22-230.dyn.iinet.net.au. [124.169.22.230]) by smtp.gmail.com with ESMTPSA id w12-20020a170902e88c00b00176ba091cd3sm5176430plg.196.2022.10.09.16.11.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Oct 2022 16:11:52 -0700 (PDT) In-reply-to: <87mta52mul.fsf@posteo.net> Received-SPF: pass client-ip=2607:f8b0:4864:20::102f; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x102f.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-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:297297 Archived-At: Philip Kaludercic writes: > Tim Cross writes: > >> >> Far better to just educate users that ANY package they install could >> contain malicious code. > > Is this feasible? Should this be a (long-)term goal, or will ELPA > always be a "use at your own risk" kind of thing? > > Also, could you clarify what you mean by "formal security review"? The amount of resources needed to ensure code has no security issues is immense - well of course you cannot always guarantee no security issues, but just having sufficient analysis to provide a reasonable level of confidence is significant. To make it worse, any such analysis needs to be done after every code update. While a casual read through of the code may identify many glaring security problems, it will miss less obvious issues. TO make matters harder, actively malicious code will be crafted to hide its intent as much as possible, so is unlikely to be identified just scanning through the code. A formal review would likely involve the following - Formal analysis of the code. More than just a casual read through of the code. This would involve reading the code with a focus on security and verifying you understood what it did by tracing data flow all the way through. This would include any packages/modules the main package also uses (if those package versions have also undergone a formal security review, you can leverage off that information and would not be required to perform such a review on them again. It also involves reading assuming there are problems and your trying to find them. - Use of various networking tools (like wireshark) to identify and understand any network traffic. Verify none of that traffic contains data which could be considered sensitive. - Understanding of all data storage used by the system and ensure where such storage involves any sensitive data that it is documented and storage protection (e.g. hashing or encryption) is implemented or easily implemented/turned on. - Actively attempt to use (abuse) the code for malicious purposes and look for possible security flaws. For example, supplying input with malicious content such as embedded code, suspect URLs, embedded commands etc. - Review of the installation and usage documentation to ensure there are not recommendations or requirements which would further reduce the user's security position. in addition, there is some housekeeping tasks which would also be required, including - Tracking when reviews are done and by who - Maintaining a registry of identified security issues. This would likely involve a high level description, severity ranking (i.e. CVSS), date discovered, date maintainers notified and possibly date for public release. Might want ot also indicate if issue is known to be actively exploited. - Formal process for handling and managing security issues What makes this extremely challenging is that the reviews should be done by people without a vested interest in the package. Package authors and maintainers are not always the best people to perform such reviews because they are too close to the code (very similar to using external testers). The real challenge here is that this stuff is a hard skill which few developers have. Finding sufficient numbers of people with these skills who are able to work on just GNU ELPA packages would be next to impossible. We simply don't have the numbers necessary. Consider the commercial 'app stores' such as Apple's, MS's Azure store or even Google Android store. These companies put significant resources into trying to ensure the apps in these stores are 'safe' (to varying degrees), yet we regularly see reports of multiple apps being removed from these stores for security reasons or about apps which have been in the store for some time and later found to be malicious. Or for something perhaps a little closer to GNU ELPA, consider the issues experienced by NPM and teh supply chain issues which have occurred there - especially with respect to those cases of trusted and widely used packages which have been compromised and that compromise was not detected for a bit of time. The NPM ecosystem is putting a lot of resources into enforcing better security practices by package maintainers as this is where many of the failures have occurred. It hasn't been the actual package repository (i.e. think GNU ELPA), but the source repositories (i.e. github, gitlab, sourceHut, random Git host) which have been compromised. The level of sound security practices employed by package maintainers varies widely. Some of the things NPM are doing to try and improve security in this area may well be informative for GNU ELPA and non-GNU ELPA. For example, sending an email to package maintainer whenever their package is updated in ELPA, requiring all source repositories to be protected with 2FA etc. The main thing protecting GNU Emacs and the ELPA infrastructure is low return on investment. Malicious intent is like many things, there has to be sufficient reward for the effort involved. The 'out run the lion' principal also factors in here (you don't need to out run the lion, you just need to not be the slowest person trying to outrun the lion). Right now, the rewards seem low and there are easier targets out there. Similar to the fallacy that there are no viruses on Apple or GNU Linux, it isn't simply that we are more secure, we just don't provide sufficient return for the effort investment. The other reason we should encourage the user to be proactive here and not have them develop the expectation that all packages in GNU ELPA are 'safe' is because a lot really depends on each individual user and how they use Emacs and in what environment. If your just using Emacs for basic code editing at home when working on hobby projects, your risk profile is likely low. However, if your a leading researcher in a extremely competitive industry, you might be a much richer target worth pursuit. If you also use Emacs to read your email, browse the web, as your window manager, to interact with databases and for accessing remote sensitive servers/data stores, then perhaps someone might target Emacs as a way to gain access or exploit your data/system. This level of targeting of researchers by well resourced industrial espionage groups (often government backed) has been of sufficient concern that the 'five eyes' have issued a number of security alerts to various government and private research organisation over the last few years.