Re: Proposal to include obligatory PGP verification of packages from any repository

[Jean Louis]

* Vasilij Schneidermann <mail@vasilij.de> [2020-10-19 21:29]:
> There is a difference between trying (enabling LibreJS and looking at
> how many scripts it blocked) and trying (enabling LibreJS and actually
> using the website while paying attention to how functional it is).  Out
> of curiosity I've attempted the latter as it's a more meaningful test,
> using the latest version of Firefox Developer Edition on Arch:

I am not using Arch for reason that they allow any kind of proprietary
software in GNU/Linux distribution, there are some freedom issues with
Firefox, so I am using IceCat derivative or Iceweasel-uxp and I could
not access activities.

Further, I am faced with the warning by Github that my browser is not
supported.

And I do know that with LibreJS enabled, many functions work, some
functions do not work. I did not test extensively.

> My verdict so far: Github almost passes the test.  If one does have an
> account already (from what I've seen you do), there is no excuse for you
> to not contribute.

I would also say if developers can use Github they can as well use
various libre online hosting systems.

> > Additionally Github.com does not support many browsers, they publicly
> > say so, which in turn means that many users of free software browsers
> > from free software distributions are unable to access Github.com,
> > users of Github are supposed to use Firefox or Chrome or Microsoft
> > Browsers, while I am using Icecat and Iceweaseal-UXP from Hyperbola
> > GNU/Linux-libre -- so my experience with Github.com is narrowed, I
> > cannot access large parts of the website.
> 
> From a security perspective it's a bad idea to use any browser outside
> of the main stream as only the largest browser vendors manage keeping up
> to speed with security issues. While one can use a browser based on
> them, there will be issues.  As a side point, Debian settled its
> trademark dispute with Mozilla and no longer offers rebranded versions
> of Firefox.  Therefore Debian users will not face browser
> incompatibility problems and avoid such security issues.

Since 2016, I am not using Debian GNU/Linux on our internal computers
for reason that they guide users to non-free firmware and help users
enable non-free repositories. I am using exclusively free software
operating systems, see: http://www.gnu.org/distros/free-distros.html

I am not sure for all of them, but I do not use what you use.

And I am not following the main stream, and I am behind bad networks,
my case is particular and personal, I am using eww, and even by using
eww I can find github.com link to clone repository, in that sense
github.com is usable, that still does not make their javascript free
software, and users of free software should not be guided to non-free
software, be it javascript.

Trisquel project, and Savannah, many others, like Gitlab, they also
offer free code hosting without proprietary software. It means all
those developers could switch.

> One does not share a package on MELPA to further the goals of the free
> software movement, one does so to reach as many Emacs users as possible
> with relatively little effort (which excludes GNU ELPA, we'll have to
> see whether the same holds true for non-GNU ELPA).

That is exactly what we are both talking about, thanks.

Packages from MELPA are not signed, can you maybe recommend from
security perspective that each author start signing their packages?

> > There is https://savannah.nongnu.org then there is Trisquel hosting,
> > they would easily add Emacs packages without problem
> > https://devel.trisquel.info/users/sign_in then there are other
> > non-free Javascript and friendly free software hosting providers.
> 
> Savannah does not strike me as an adequate alternative for people used
> to Github.  For starters it requires approval of each project before
> it's publicly visible.  I'll have to do a proper evaluation of it though
> before I can comment further on this aspect.  Gitlab is the closest
> equivalent, though not perfect either.  For minimalism and integration
> of an email-centric workflow sourcehut looks ideal, once it leaves its
> alpha status.

Maybe also the money is problem, as maintainers would by hosting
themselves, be paying themselves.

But price of freedom we all pay.

I make extensive travels to find proper computers that I can liberate
from Intel spying engine, and install libreboot, so the price I am
paying personally, so the price for hosting can be also somehow paid.

Various projects such as Trisquel would be welcoming new Emacs package
developers on their Gitlab instances.

> > For me largest security problem on MELPA is that Github.com is run by
> > Microsoft, we have no idea what principles they share beyond
> > commercial principles, and the more Emacs packages are hosted on
> > Microsoft Github, the more probability is there for mischievous
> > conduct or security breaches.
> > 
> > Same can be said for hosting providers that value free sofware,
> > security breaches are possible, but then we would know that people
> > maintaining the server do care of users enough, to prevent mischievous
> > conduct.
> 
> This argument does not follow.  A code forge can have security issues,
> no matter whether its code can be freely audited or the political
> alignment of its owners.  Merely being concerned about free software
> doesn't mean that security issues will be investigated and acted upon,
> neither does ownership by an entity pursuing different goals mean it
> will neglect security issues.

I am very practical, I am trusting OpenBSD various teams to make the
LibreSSL how it should be, I am trusting them with various security
issues like in OpenSSH, for reasons of their principles set long time
ago. So I am trusting various smaller communities such as those of
Guix, Trisquel, Hyperbola GNU/Linux-libre, for reason that they act
upon the notices related to freedom, security, you name it. For their
agility and responsiveness. I trust GNU packages and people behind it
for obviously good responsiveness in handling user issues or bugs.

I cannot trust Archlinux to handle issues of freedom because their
policy is such that they will include proprietary software if
proprietor is allowing them, and if they have such policy, then I
cannot trust them with security issues too.

You are right that all hostings or let us say digital backgrounds can
be compromised, but if proprietary background is compromised such as
Microsoft Github, for reasons of their business interests I cannot
trust them to be transparent, unless third party have found security
issue.

For free software communities, some of them I mentioned, I can trust
them based on my experience with them, to be very transparent with
security issues.

> > A package can be thus accepted in MELPA and become approved, then
> > later continuously updated, meaning without any control or
> > supervision, and then automatically offered to users. Backdoor can be
> > injected into users' Emacs and run on their computers. If I am wrong
> > on how MELPA works, you may tell me, that is what I understood from
> > their website.
> 
> That is indeed correct, there is no further quality assurance after the
> initial submission.  It takes a significant amount of time for that
> submission to be verified due to the few reviewers and given the sheer
> amount of packages (4750 packages at the time of writing), I do not see
> this working out with their current team.  For comparison, Arch has
> "Trusted Users" responsible for their official packages, with anywhere
> between 5 and 90 packages assigned to each of them.  Rest assured that
> they don't perform security audits, only basic quality assurance as
> packages are updated and bugs trickle in.  Having the kind of work force
> a GNU/Linux distribution has is a luxury, not something to take for
> granted.

What that setup of Archlinux does is that it decentralizes the package
delivery, so some of those maintainers will indeed look into code and
report issues when found, there is more care and automatically there
is more responsibility. I do not say how much, I just can think that
it is.

Security and freedom issues are mostly promptly handled in those FSF
endorsed distributions, those are significant differences originating
from various group attitudes or set of principles.

> That aside, how does this quality assurance look like for GNU ELPA?

I understand it fully and I wish more security in any kind of package
repository for GNU Emacs, as users are downloading blindly "packages"
many of them will find it funny, and most of time nothing bad will
happen until it happens.

> Is it users subscribing to a commit mailing list and looking out for
> anything suspect?  Fewer releases overall?  A basic level of vetting
> by asking for copyright assignment?  I doubt that code is audited
> for every release either and that security issues are instead dealt
> with in a reactive instead of proactive manner (meaning, as soon as
> one is known of, appropriate measures such as a security release are
> taken).  There is a lot more work to be done here, such as defining
> a comprehensive threat model to work with.  Another important
> aspect: Say that non-GNU ELPA manages to catch up with MELPA in
> terms of package count, does the existing review system still work?
> Will new measures be necessary to guarantee security (for example by
> designing packages in terms of a more restrictive approach with
> permissions, sandboxing and whatnot)?  I strongly suspect that they
> will be and merely mirroring MELPA packages won't suffice.

Thank you for thinkering about security. Resource scarcity is security
issue.

For GNU ELPA I know that principle is that packages are assigned with
copyright to FSF and by other principles which I am not authorized to
represent.

While it is great to have large choice, number of packages in an
archive is for sure not the principle for GNU ELPA.

For me personally, that count is not a feature, it is anti feature,
the more packages they are, the more I get concerned for reasons
explained by me, and reasons explained by you.

> > SO FAR I KNOW there is no system of signing packages and verification
> > of such. I have verified MELPA git, and I cannot find that they are
> > using GnuPG or gpg or other system that packages were really made by
> > the author they claim to be made. This may be true at GNU ELPA too, I
> > did not verify it, but I know at that GNU ELPA is not automatically
> > built and offered to users blindly without verification (I at least
> > believe they are verified).
> 
> As mentioned above, MELPA's principle of going with the most convenient
> option makes this a non-starter.  Vetting package authors for their
> identity, requiring a GPG key and signed releases is something I'd
> rather expect for GNU ELPA than them.

Turn on the option package-check-signature and start verifying.

> > 1. Github.com may not even know if somebody cracks some developer's
> >    account and changes few packages to misbehave, if they would be
> >    alerted, they would not maybe act in the best interest of the free
> >    software project, they would act in their own best interest.
> 
> Github offers 2FA to protect accounts and has a dedicated security team
> reacting to incidents.

See this example:
https://pberba.github.io/security/2020/05/28/lastpass-phishing/

You are right that neither free software repositories need be secure,
they have though different motivation and different level of
transparency as they do not work for their number of sales and good
image, they are more proud if they find their security incidents
themselves, speaking of OpenBSD principles of work.

> That aside, it's not even necessary to hack an account to distribute
> malicious software.  Popular package archives for other programming
> languages have seen attacks such as typo squatting [4]creating
> (uploading a package with a misleading name) and hostile maintainers [5]
> (where a package is transfered to a new maintainer who then abuses the
> trust created by the package by adding malicious code to it).  I have to
> confess I've pondered creating a malicious package for demonstrating how
> easy it would be to sneak something in without anyone noticing, but I'm
> afraid it will only lead to more emails sowing Fear, Uncertainty and
> Doubt.  Or people weaponizing the code, not sure is likelier.

You have got references, to me it is obvious. What I am surprised is
that I do not know of serious security incidents within Emacs
packages, that does not mean they are not about to come.

> Emacs does have basic verification already, but it is far from ideal.
> The failure case is not handled well at all, users are not told what to
> do when it fails verifying a package and are inclined to instead disable
> the mechanism once and for all.

Right.

> If an Emacs is too old to contain the appropriate GPG keys, the
> keyring will be needed to be updated outside of Emacs, a task that
> can fail for opaque reasons due to key servers being unreachable.
> There is initial work in form of the gnu-elpa-keyring-update package
> distributed via GNU ELPA, but it suffers from a bootstrapping
> problem and needs to be installed *before* the keys become outdated.
> Until this issue is solved, I cannot imagine making this opt-out or
> even mandatory.  For comparison, Arch ships its own package manager
> specific GPG keyring and updates it during each package update
> operation.

That is about that what I expect for Emacs as well!

Jean

P.S. Think about implementing OMEMO in Jabber.el, my offer stands