Tim Cross <theophil...@gmail.com> writes: > and people constantly use M-x package-install to install packages > from GNU ELPA, nonGNU ELPA and MELPA, often with this misguided belief > that these packages are being vetted by the security fairies.
Yes, and no. There is still a world of a difference between "any random website can attack me when I just navigate there" and "installing a package may not be safe". This is a false whatabout: That packages are not safe does not mean that attacks by any random website aren’t much *more* dangerous. > While adding the sorts of controls you outline is not a bad idea, I > think it is far more important to train people to accept that their > system simply is not secure. This treats security as a boolean. It is not. The chance and impact of a breach matter a lot, and any random website being able to exploit a weakness in org-mode incleases the chance and impact a lot. That Emacs is not perfect does not mean that it doesn’t matter if we make it worse. > You should start from the position that > Emacs is not secure. Why? Because it is a large, complex and powerful > piece of software which has no formal security analysis or testing and > is usually augmented with numerous packages of unknown quality from > largely unknown sources. Essentially, Emacs already suffers from all the > same issues identified for systems like node and the NPM ecosystem. Yes. We should avoid adding *one more* issue that is actually worse than the others. And yes, we should rather reduce the number of packages we rely on. I’ve done that multiple times in the past. > The only think which is really providing protection for us Emacs users > is that the rewards for compromising Emacs are too low for the effort > required. Similar to why you don't see many viruses on macOS - it isn't > that it is significantly more secure than Windows (these days), but > rather the pool of potential 'targets' and scale of rewards are higher > when you focus on the Windows environment. It is all about return on > investment. This is no longer true about macOS. It has grown to be a large target, but it still is hard to crack. Windows became safer by starting to add safeguards (like asking the user for admin rights before doing admin stuff — essentially sudo) and taking security seriously. > update after formal review and testing of updated version, don't use > Emacs for email or web browsing, only run emacs in an isolated locked The point here is: Without auto-switching to org-mode, using emacs for web browsing is likely reasonably safe. Adding this as default would remove that. > Even if you decide your risks are low, you may still decide to not use > Emacs for some purposes. For example, you might decide not to use Emacs > for password management or not use Emacs packages which require you to > keep sensitive data (toekns, passwords, API keys etc) using insecure > mechanisms etc. You describe that whenever we do not care about security for some mechanism, this removes this part of Emacs from the features people with some security needs can use. It breaks the integration of Emacs — which is one of its biggest strengths — if we have to say “for convenience we enabled opening any web document automatically in org-mode, so if you think that unsafe, don’t browse the web with Emacs *anymore*”. As secure as we can should be the default, not "change these random configuration settings and avoid those features to get some security". Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
