Re: Fwd: Should package.el support notifying on package security updates?

[Tim Cross <theophilusx@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > That makes sense. But I only brought up the MELPA example because I
>   > recently encountered a security bug in a MELPA package. There's no reason
>   > ELPA packages can't have similar security bugs (I just don't have an
>   > example of this at the moment), and I figured it might be a good idea to
>   > have some support for making it easier for users to quickly get security
>   > updates for packages, regardless of what repository they're using.
>
> We can do that for the repositories that we support, whose packages we
> can fix or whose maintainers have some relationship with us.  We have
> no relationship with MELPA -- if you use that, you're on your own.
>
> We do copy some packages from MELPA into NonGNU ELPA.  It takes a
> little discussion, making sure the package does and will satisfy some
> basic criteria.  But if the package is popular, we're glad to do that.
> You can ask us to move the packages you use, if they are popular.
>
> Do we support the NonGNU ELPA packages well enough now
> for security updates?

No and nor are the main elpa packages supported sufficiently enough to
implement a concept of security updates.

Once yhou distinguish updates such that you now include security updates
(in a similar manner to GNU Linux distributions like Debian, Fedora
etc), you create the expectation that

- there is some formal review and management of security issues. There
  isn't

- Packages are being reviewed and monitored for security issues. They
  are not.

- Updates not flagged as security updates do not have a security
  implication. This may not be true.

Essentially, all this will do is create a false sense of security. Users
will believe that provided they have applied all packages marked as
security updates that their system has no packages with known security
issues. As we don't have any formal tracking or management of security
issues and as we don't do any systematic or formal review of packages in
either GNU ELPA or non-GNU ELPA, we cannot provide and we should not
give the impression of providing any level of security assurance. In
fact, we should likely go completely the other direction and educate
users that when they add packages, especially non-GNU packages, it is
completely at their own risk.

The main reason there hasn't been a major security issue with Emacs and
the package system is down to good luck, not due to good security
policy. If Emacs was more popular and had a larger user base, making it
a richer target for those interested in compromising systems, we would
see similar problems to those experienced by NPM, Google and Apple
stores etc. All that is really protecting us now is that the rewards for
doing such are lower than the effort required to pull it off and we have
a few people who do informal scanning/reviewing of code (which is great,
but provides little formal assurance and is unlikely to pick up cleverly
crafted exploits which are designed to defeat such informal scans).  

What we could do which may provide some benefit to users is implement a
policy or practice which encourages package maintainers to label
security related changes in change logs or readme files in a specific
manner/format which makes them easy to spot. It is likely those who are
interested in security issues will check these files before applying
updates anyway. Those who just blindly apply updates are unlikely to
really be paying sufficient attention to security risks to benefit
anyway.