Re: Security issues in Emacs packages
Tim, > At the end of the day, this is essentially a supply chain problem. To > really have confidence, you need confidence in the whole supply chain, > not just the distribution centre. that makes sense. thanks. Greg
Re: Security issues in Emacs packages
* Tim Cross [2020-11-27 01:21]: > > Greg Minshall writes: > > > Tim, > > > >> It could, but to get that level of assurance, you not only have to > >> verify the signature is valid (something which is automated if > >> enabled), you also need to verify that both packages have the exact > >> same signature, which is pretty much a manual process. So in addition > >> to telling you the version number, George would also need to > >> communicate the signature and that would need to be compared to the > >> signature you have in the package you downloaded to know that the > >> packages are in fact the same (you cannot rely on version numbers for > >> any real verification). > > > > if MELPA's release procedure prevented two separate releases of version > > 1.2.3 of package xYandZ from being released, wouldn't that obviate the > > requirement for George to give me signatures? that was my thought as to > > why a signed (MELPA, version number, package name) would be enough. > > (i've no idea if MELPA's procedures would actually conform to my > > "requirement".) > > > > Possibly, but I'm not sure it does/can. From my limited understanding, > the version number is determined by the git tag (for stable packages - I > think the date is used for unstable). This is as it should be as it > should be the package maintainer who controls the version number, not > the packaging service (especially for maintainers who use semantic > versioning where the version number actually conveys information about > the package). Before some days or weeks we discussed this in a different thread, not this mailing list. I think emacs-devel. Authors are by convention writing their version numbers in their packages aligned to the Emacs Lisp manual section on Packaging. MELPA is injecting their version they are taking from git as commit number. Thus MELPA does not use author's version number. It should be obvious from package-list-packages that same version of the package in GNU ELPA does not have same version number in MELPA, that is confusion created for no good reason but to minimize programming efforts at MELPA. > At the end of the day, this is essentially a supply chain problem. To > really have confidence, you need confidence in the whole supply chain, > not just the distribution centre. Either way it could be good and depends what does the distribution center do. If they are auditing packages and making sure of security or are they just packaging without any audit. Maybe distribution center verifies all PGP signatures and we may trust such center, maybe not. The OpenBSD software audits packages. It cannot ever be fully secure but for base system one can rest assured that developers have put a lot of effort in making it secure. Trust with users is then created based on the relation and background of the OS distribution. > Personally, I wish both GNU and Melpa had adopted a push mechanism for > package release. Something similar to npmjs.com where the package > author/maintainer would submit a signed package (publish) to the > repository. This would make it producers of the package code we trust, > not the distribution center (repository). I wish that too.
Re: Security issues in Emacs packages
Greg Minshall writes: > Tim, > >> It could, but to get that level of assurance, you not only have to >> verify the signature is valid (something which is automated if >> enabled), you also need to verify that both packages have the exact >> same signature, which is pretty much a manual process. So in addition >> to telling you the version number, George would also need to >> communicate the signature and that would need to be compared to the >> signature you have in the package you downloaded to know that the >> packages are in fact the same (you cannot rely on version numbers for >> any real verification). > > if MELPA's release procedure prevented two separate releases of version > 1.2.3 of package xYandZ from being released, wouldn't that obviate the > requirement for George to give me signatures? that was my thought as to > why a signed (MELPA, version number, package name) would be enough. > (i've no idea if MELPA's procedures would actually conform to my > "requirement".) > Possibly, but I'm not sure it does/can. From my limited understanding, the version number is determined by the git tag (for stable packages - I think the date is used for unstable). This is as it should be as it should be the package maintainer who controls the version number, not the packaging service (especially for maintainers who use semantic versioning where the version number actually conveys information about the package). At the end of the day, this is essentially a supply chain problem. To really have confidence, you need confidence in the whole supply chain, not just the distribution centre. Personally, I wish both GNU and Melpa had adopted a push mechanism for package release. Something similar to npmjs.com where the package author/maintainer would submit a signed package (publish) to the repository. This would make it producers of the package code we trust, not the distribution center (repository). Main downside with that approach is you would also need a reliable mechanism for retrieving the public keys (there would be a lot more of them to manage). I also think this would be a model that is a lot easier to scale (something I think GNU will have problems with under their current model. -- Tim Cross
Re: Security issues in Emacs packages
Tim, > It could, but to get that level of assurance, you not only have to > verify the signature is valid (something which is automated if > enabled), you also need to verify that both packages have the exact > same signature, which is pretty much a manual process. So in addition > to telling you the version number, George would also need to > communicate the signature and that would need to be compared to the > signature you have in the package you downloaded to know that the > packages are in fact the same (you cannot rely on version numbers for > any real verification). if MELPA's release procedure prevented two separate releases of version 1.2.3 of package xYandZ from being released, wouldn't that obviate the requirement for George to give me signatures? that was my thought as to why a signed (MELPA, version number, package name) would be enough. (i've no idea if MELPA's procedures would actually conform to my "requirement".) cheers, Greg
Re: Security issues in Emacs packages
* Greg Minshall [2020-11-26 08:29]: > Tim, > > > I think you missed my point. There is no benefit in MELPA adopting > > signed packages because there is no formal code review and no vetting > > of the individuals who submit the code. > > it occurs to me there might be one benefit: if George, whom you trust, > says, "I've been running version 1.2.3 of package xYandZ from MELPA and > i have a lot of confidence in it", then if you find that version of that > package with a trusted MELPA signature, you maybe know that you and > George are running the same software. i.e., it helps with the "web of > trust" (if people still talk of that). > > (so, the requirement for this is not audited packages, but a solid, > "secure", release procedure by MELPA.) Maybe principles from Freenet Web of Trust could be somehow implemented for Emacs users and our discussions. https://www.draketo.de/english/freenet/friendly-communication-with-anonymity
Re: Security issues in Emacs packages
Jean Louis writes:
> * Tim Cross [2020-11-26 02:40]:
>> > 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.
>
> I did before some time.
>
>> 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.
>
> I have not seen that, and I have assumed you would know better and
> wanted to see how authors are reporting that package is ready for
> release and I do not see that.
>
> Recipes are like this:
>
> (0blayout :repo "etu/0blayout-mode" :fetcher github)
>
> (0x0 :url "https://git.sr.ht/~zge/nullpointer-emacs"; :fetcher git)
>
> (0xc :fetcher github :repo "AdamNiederer/0xc")
>
> So that recipe alone does not tell me that author reports that new
> package is ready, it is fetched from git, but there are parts of code
> that I did not see that is why I am assuming you know it better.
>
>> Your model is flawed. You can have both automatic pulling AND author
>> control over when a new package is issued.
>
> To make it practical tell me where is that author's control?
>
> I have quick view of files and any recipe files in directory
> melpa/recipes do not give me any pointers, it is all automated and
> fetched from git.
>
>> 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.
>
> You seem to be very confident and for this reason I assume you know it
> better, but due to contradictions please show one practical recipe or
> package where author has control on when is package ready to be
> released.
>
> $ grep sha *
>
> on recipes does not give any reference.
>
> $ grep commit *
>
> eval-in-repl: :commit "origin/master")
> git-auto-commit-mode:(git-auto-commit-mode :fetcher github :repo
> "ryuslash/git-auto-commit-mode")
> git-commit:(git-commit :fetcher github
> git-commit::files ("lisp/git-commit.el")
> git-commit::old-names (git-commit-mode))
> git-commit-insert-issue:(git-commit-insert-issue :fetcher gitlab :repo
> "emacs-stuff/git-commit-insert-issue")
> vc-auto-commit:(vc-auto-commit :fetcher github :repo "thisirs/vc-auto-commit")
> what-the-commit:(what-the-commit :fetcher github
> what-the-commit: :repo "danielbarbarito/what-the-commit.el")
>
> So there is nothing I can find that points or references to what you
> say.
>
>> 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.
>
> I am sorry I do not see reference to it. You are convincing but I do
> not see reference.
>
> Recipe for bar-cursor:
> (bar-cursor :repo "ajsquared/bar-cursor"
> :fetcher github)
>
> Recipe for magit:
>
> (magit :fetcher github
>:repo "magit/magit"
>:files ("lisp/magit"
>"lisp/magit*.el"
>"lisp/git-rebase.el"
>"Documentation/magit.texi"
>"Documentation/AUTHORS.md"
>"LICENSE"
> (:exclude "lisp/magit-libgit.el"
>;; Cannot remove this yet because it would
>;; also be removed from the stable version.
>;; "lisp/magit-section.el"
>)))
>
> Repo magit/magit:
> https://github.com/magit/magit
>
> I have given you references, maybe I cannot read that well, so you can
> give me references to show if authors have participation in decision.
>
The available recipe options are all clearly documented in the README
for the melpa repository. Most maintainers don't use the :commit option
because it is extremely inconvenient, but it is there if they want it.
It is inconvenient because it means the recipe has to be updated, which
means a pull request has to be accepted before the package can be released.
Most maintainers will maintain a specific branch for releases. This is
normal practice in version control. Often, this is the master branch,
but 'release' and 'melpa' are also commonly used. Code is not pushed
onto these branches until it is ready for release. The package
maintainer has full control of this branch and therefore has full
control over when new code is released. This is also the model used by
GNU ELPA for external packages.
This is not the model you imply, where MELPA just grabs the data
whenever it wants and releases new version without management by the
package maintainer, resulting in the release of code that is not ready
for release.
--
Tim Cross
Re: Security issues in Emacs packages
Greg Minshall writes: > Tim, > >> I think you missed my point. There is no benefit in MELPA adopting >> signed packages because there is no formal code review and no vetting >> of the individuals who submit the code. > > it occurs to me there might be one benefit: if George, whom you trust, > says, "I've been running version 1.2.3 of package xYandZ from MELPA and > i have a lot of confidence in it", then if you find that version of that > package with a trusted MELPA signature, you maybe know that you and > George are running the same software. i.e., it helps with the "web of > trust" (if people still talk of that). > > (so, the requirement for this is not audited packages, but a solid, > "secure", release procedure by MELPA.) > It could, but to get that level of assurance, you not only have to verify the signature is valid (something which is automated if enabled), you also need to verify that both packages have the exact same signature, which is pretty much a manual process. So in addition to telling you the version number, George would also need to communicate the signature and that would need to be compared to the signature you have in the package you downloaded to know that the packages are in fact the same (you cannot rely on version numbers for any real verification). Signatures are a good thing and MELPA should implement them. However, what they are really useful for is ensuring the package you have downloaded has not been modified since it was created and signed. -- Tim Cross
Re: Security issues in Emacs packages
Tim, > I think you missed my point. There is no benefit in MELPA adopting > signed packages because there is no formal code review and no vetting > of the individuals who submit the code. it occurs to me there might be one benefit: if George, whom you trust, says, "I've been running version 1.2.3 of package xYandZ from MELPA and i have a lot of confidence in it", then if you find that version of that package with a trusted MELPA signature, you maybe know that you and George are running the same software. i.e., it helps with the "web of trust" (if people still talk of that). (so, the requirement for this is not audited packages, but a solid, "secure", release procedure by MELPA.) cheers, Greg
Re: Security issues in Emacs packages
* Tim Cross [2020-11-26 02:40]:
> > 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.
I did before some time.
> 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.
I have not seen that, and I have assumed you would know better and
wanted to see how authors are reporting that package is ready for
release and I do not see that.
Recipes are like this:
(0blayout :repo "etu/0blayout-mode" :fetcher github)
(0x0 :url "https://git.sr.ht/~zge/nullpointer-emacs"; :fetcher git)
(0xc :fetcher github :repo "AdamNiederer/0xc")
So that recipe alone does not tell me that author reports that new
package is ready, it is fetched from git, but there are parts of code
that I did not see that is why I am assuming you know it better.
> Your model is flawed. You can have both automatic pulling AND author
> control over when a new package is issued.
To make it practical tell me where is that author's control?
I have quick view of files and any recipe files in directory
melpa/recipes do not give me any pointers, it is all automated and
fetched from git.
> 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.
You seem to be very confident and for this reason I assume you know it
better, but due to contradictions please show one practical recipe or
package where author has control on when is package ready to be
released.
$ grep sha *
on recipes does not give any reference.
$ grep commit *
eval-in-repl: :commit "origin/master")
git-auto-commit-mode:(git-auto-commit-mode :fetcher github :repo
"ryuslash/git-auto-commit-mode")
git-commit:(git-commit :fetcher github
git-commit::files ("lisp/git-commit.el")
git-commit::old-names (git-commit-mode))
git-commit-insert-issue:(git-commit-insert-issue :fetcher gitlab :repo
"emacs-stuff/git-commit-insert-issue")
vc-auto-commit:(vc-auto-commit :fetcher github :repo "thisirs/vc-auto-commit")
what-the-commit:(what-the-commit :fetcher github
what-the-commit: :repo "danielbarbarito/what-the-commit.el")
So there is nothing I can find that points or references to what you
say.
> 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.
I am sorry I do not see reference to it. You are convincing but I do
not see reference.
Recipe for bar-cursor:
(bar-cursor :repo "ajsquared/bar-cursor"
:fetcher github)
Recipe for magit:
(magit :fetcher github
:repo "magit/magit"
:files ("lisp/magit"
"lisp/magit*.el"
"lisp/git-rebase.el"
"Documentation/magit.texi"
"Documentation/AUTHORS.md"
"LICENSE"
(:exclude "lisp/magit-libgit.el"
;; Cannot remove this yet because it would
;; also be removed from the stable version.
;; "lisp/magit-section.el"
)))
Repo magit/magit:
https://github.com/magit/magit
I have given you references, maybe I cannot read that well, so you can
give me references to show if authors have participation in decision.
Jean
Re: Security issues in Emacs packages
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
Re: Security issues in Emacs packages
* Tim Cross [2020-11-26 01:47]: > I think you missed my point. There is no benefit in MELPA adopting > signed packages because there is no formal code review and no vetting of > the individuals who submit the code. Do you think it is really their reason? Or maybe you are developer in MELPA? There is still difference if package comes from MELPA or from third party archive, definitely signing would say this package was signed by MELPA and other package was not signed by trusted key, so who is that? Is the MD5SUM same as original? It would give some initiative to investigate. Packages are not audited that is so. I think audit can be quick by using grep for some dangerous commands, I have already found rm -rf as example command in one of packages, not as malicious one. One could search for (shell-command and verify such and similar functions. > If you have no controls in place over the contents of what is being > signed, the value of the signatures as a security measure is > drastically reduced. Yes, the valid signature may provide some > assurances as to where the package originated, but that means little > if the contents could be anything. What you explain is logical to me, users though need better information. One big DANGER should be given to users. > As it stands, the signing of ELPA packages only provides assurance that > they are packages assembled by GNU. These signatures do not provide any > real assurance regarding the content of the packages other than they are > GPL's and do not recommend or encourage the use of non-free > software. There is no absolute. Signing says about origins. Mirrors are placed anywhere in the world, including behind Internet. It is one way for users to verify origin and if source has been changed. > The question is what level of trust should you assume. With ELPA, all > you can really trust is that the package has a GPL license and does not > recommend/require the use of non-free software. There is little trust > that the package does not do something malicious or includes code which > may compromise the user's security. to provide that level of assurance, > you would need formal code reviews, which is not feasible given > available resources. Last month I could see that several packages were here and there improved by developers so they do look into code and how much they do I cannot know. > I think it is important users are aware of this > limitation. Furthermore, I ask the question "Does having signed > packages imply a level of expected assurance which is higher than it > really is?" In other words, do users expect that a package is > completely safe just because it was downloaded from an official GNU > ELPA repository? Download numbers on MELPA tells me that answer should be rather positive, any package is safe to be installed. See numbers. Information is no enough to teach users. More attention is necessary. > Last time I looked, ELPA also supported 'external' packages where the > data is retrieved from an external git repository. I think org is one > such package. Majority of GNU ELPA packages are external how I know about it, but authors decide WHEN to upload them. > > The point number (1) is human, not automated. Author decides when is > > the package ripe for distribution and what is "release". > > > > Git repository is never release and not meant to be "release". Git is > > for collaborative development and users are made blind that it is some > > kind of release while it is not. One shall always assume that Git > > repository contains development versions not ready for public. > > > > Why? This is not normal. Git repositories contain all versions, both > production and development. What is production and what is development > is managed through branches and tags. Anyone who wants can clone the > ELPA git repository. How I see practically, people hack on git master branches and main branch need not be considered release ready. Git hosting websites then have special section for releases. Git branch is not a release according to what I know, it is revision control system or version control system. Git often looks pretty different than release as package. Of course everybody can clone. Point is that software is no ripe. Maybe somebody else knows if Git can tell that software is ripe, what I know it is not so. Author has to say when it is ripe for release. > > MELPA pulls those packages, correct me if I am wrong, automatically > > from Git repositories without regard if the package is actually > > release. That does not align or respect the established Emacs > > conventions how packages should be released, if they are multi files > > they should be in .tar file otherwise .el and there are version > > numbers that MELPA fiddles with and makes possible conflicts and > > introduces confusions. > > 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 da
Re: Security issues in Emacs packages
Jean Louis writes: > * Tim Cross [2020-11-25 10:01]: >> >> Jean Louis writes: >> >> > * Tim Cross [2020-11-24 23:40]: >> >> If people are really concerned about security, they should look first at >> >> their use of repositories like MELPA. There is no formal review or >> >> analysis of packages in these repositories, yet people will happily >> >> select some package and install it. >> > >> > Interesting that you are one who mentions that. There are just few >> > people ever mentioned it. >> > >> > I am still in process of the review of MELPA packages and its >> > system. There are many security issues. >> > >> > Package signing is one example. It does not offer much of security >> > when packages are signed automatically, but it raises level of >> > security. >> > >> > MELPA packages and archive-contents are not PGP signed, while GNU ELPA >> > packages are signed. >> > >> >> IMO signing of packages is irrelevant when there is no formal review >> process or even any formal process to verify the credentials of >> signatures. In fact, just adding signing would likely be >> coutner-productive as it would give the impression of some sort of >> security where there is none. > > When user receives a signed package from GNU ELPA, that means it comes > from GNU ELPA. If signed package is then distributed by mirrors or > other websites users who enable package signature verifications will > know that package still comes from GNU ELPA, and not from Chinese > distributor. If the package is tampered the signature verification > will not allow installation of the package. > I think you missed my point. There is no benefit in MELPA adopting signed packages because there is no formal code review and no vetting of the individuals who submit the code. If you have no controls in place over the contents of what is being signed, the value of the signatures as a security measure is drastically reduced. Yes, the valid signature may provide some assurances as to where the package originated, but that means little if the contents could be anything. The situation with ELPA is a little better because those who maintain the code are required to assign legal copyright to GNU. However, I'm not sure how much checking is done to verify the information in those assignments. As far as I know, there is no formal code review. A number of the Emacs developers do perform some informal review, but as we all know from the issues with openssl, informal reviews provide little assurance. This is not a criticism of GNU or emacs developers. The amount of resources necessary to perform formal review is much larger than the available resources. On the whole, the emacs user community appears to be happy with the current situation. If they were not, it would be on the community to step up and do something about it. As it stands, the signing of ELPA packages only provides assurance that they are packages assembled by GNU. These signatures do not provide any real assurance regarding the content of the packages other than they are GPL's and do not recommend or encourage the use of non-free software. > That it does add to security shows the fact that GNU/Linux > distributions do sign packages. There is difference if the package > comes from trusted source or not trusted source. > The question is what level of trust should you assume. With ELPA, all you can really trust is that the package has a GPL license and does not recommend/require the use of non-free software. There is little trust that the package does not do something malicious or includes code which may compromise the user's security. to provide that level of assurance, you would need formal code reviews, which is not feasible given available resources. I think it is important users are aware of this limitation. Furthermore, I ask the question "Does having signed packages imply a level of expected assurance which is higher than it really is?" In other words, do users expect that a package is completely safe just because it was downloaded from an official GNU ELPA repository? >> Basically, anyone can upload anything to MELPA. > > Maintainers verifies the package initially for certain conventions, > after that, how I have understood it, packages are automatically > pulled from Git. The more authors give packages to MELPA the more > insecurity probability is raised. > > GNU ELPA how I understand it, I may be wrong, works like this: > > 1) packages are uploaded to GNU ELPA > 2) then automatically signed by GNU ELPA PGP keys > 3) offered for distribution > Last time I looked, ELPA also supported 'external' packages where the data is retrieved from an external git repository. I think org is one such package. > The point number (1) is human, not automated. Author decides when is > the package ripe for distribution and what is "release". > > Git repository is never release and not meant to be "release". Git is > for collaborative development and users are made blind that it is some > kind of
Re: Security issues in Emacs packages
On Wed, Nov 25, 2020 at 12:26:11PM +0300, Jean Louis wrote:
> * to...@tuxteam.de [2020-11-25 12:08]:
> > On Wed, Nov 25, 2020 at 11:23:27AM +0300, Jean Louis wrote:
> >
> > [...]
> >
> > > [...] and not from Chinese distributor [...]
> >
> > I think this was an unnecessary slur.
>
> Why, there is legitimate mirror in China.
>
> I did not mean nothing wrong with it. I hope nobody gets offended.
I'm not. I don't assume (even suspect) bad intention at all.
And I don't want to make a state affair of it. I just wanted
to mirror the metaphor you used ("Chinese distributor" as
"untrusted instance") which seems somewhat problematic. We
all do this, myself not the least. I'm happy whenever someone
points that out to me.
That's all :-)
Cheers
- t
signature.asc
Description: Digital signature
Re: Security issues in Emacs packages
* to...@tuxteam.de [2020-11-25 12:08]: > On Wed, Nov 25, 2020 at 11:23:27AM +0300, Jean Louis wrote: > > [...] > > > [...] and not from Chinese distributor [...] > > I think this was an unnecessary slur. Why, there is legitimate mirror in China. I did not mean nothing wrong with it. I hope nobody gets offended. I was just thinking on mirrors like when using /etc/apt/sources.list on Debian GNU/Linux and sources come from let us say "Digital Ocean" servers. It is not official mirror of Debian, but if packages are signed by Debian keys then I do not mind as I know they are not tampered. I hope I have expressed myself now more clear.
Re: Security issues in Emacs packages
On Wed, Nov 25, 2020 at 11:23:27AM +0300, Jean Louis wrote: [...] > [...] and not from Chinese distributor [...] I think this was an unnecessary slur. Cheers - t signature.asc Description: Digital signature
Security issues in Emacs packages
* Tim Cross [2020-11-25 10:01]: > > Jean Louis writes: > > > * Tim Cross [2020-11-24 23:40]: > >> If people are really concerned about security, they should look first at > >> their use of repositories like MELPA. There is no formal review or > >> analysis of packages in these repositories, yet people will happily > >> select some package and install it. > > > > Interesting that you are one who mentions that. There are just few > > people ever mentioned it. > > > > I am still in process of the review of MELPA packages and its > > system. There are many security issues. > > > > Package signing is one example. It does not offer much of security > > when packages are signed automatically, but it raises level of > > security. > > > > MELPA packages and archive-contents are not PGP signed, while GNU ELPA > > packages are signed. > > > > IMO signing of packages is irrelevant when there is no formal review > process or even any formal process to verify the credentials of > signatures. In fact, just adding signing would likely be > coutner-productive as it would give the impression of some sort of > security where there is none. When user receives a signed package from GNU ELPA, that means it comes from GNU ELPA. If signed package is then distributed by mirrors or other websites users who enable package signature verifications will know that package still comes from GNU ELPA, and not from Chinese distributor. If the package is tampered the signature verification will not allow installation of the package. Variable package-check-signature is not enabled by default and it is due to similar issue just as local variables. Users who seek to verify the credential of the signatures can do so in human non-automated way as that is also how GnuPG instructions advise users to do so. The GPG/PGP keys are in ~/.emacs.d/elpa/gnupg/ and users can contact GNU ELPA maintainers and verify the signature. M-x package-install will automatically verify signatures if the option package-check-signature has been enabled. That it does add to security shows the fact that GNU/Linux distributions do sign packages. There is difference if the package comes from trusted source or not trusted source. > Basically, anyone can upload anything to MELPA. Maintainers verifies the package initially for certain conventions, after that, how I have understood it, packages are automatically pulled from Git. The more authors give packages to MELPA the more insecurity probability is raised. GNU ELPA how I understand it, I may be wrong, works like this: 1) packages are uploaded to GNU ELPA 2) then automatically signed by GNU ELPA PGP keys 3) offered for distribution The point number (1) is human, not automated. Author decides when is the package ripe for distribution and what is "release". Git repository is never release and not meant to be "release". Git is for collaborative development and users are made blind that it is some kind of release while it is not. One shall always assume that Git repository contains development versions not ready for public. MELPA pulls those packages, correct me if I am wrong, automatically from Git repositories without regard if the package is actually release. That does not align or respect the established Emacs conventions how packages should be released, if they are multi files they should be in .tar file otherwise .el and there are version numbers that MELPA fiddles with and makes possible conflicts and introduces confusions. In GNU ELPA authors decide when package is release ready and when it should be released. In MELPA authors only apply for their packages to be pulled out automatically and offered for distribution. Both repositories could be compromised but probability is becoming larger and larger that by automatic pulling of packages something worse happens. MELPA cannot know possibly who is behind authors who offer those packages for distribution and who has access or who may do something malicious. Some new similar package like angry-police-captain could serve for potential attacks. #+TITLE: <2020-10-23 Fri 18:28> WTF angry-police-captain #+AUTHOR: Jean Louis - This should scrap information from a third party unknown website and show it in minibuffer. Function does not work, and yes, it is just one function inside. Good example of nonsensical "packages". *Deleted* While similar packages can be made for entertainment they can be also used to track users and save data that should not be saved. Update to this package would not be checked by MELPA, and users who have enabled it would continue using it. And package could suddenly start doing something else. Author of the package could know how many users are using it as package is actually fetching from their website. By fetching the information from website the website can know many things about those users such as their locations, operating system and versions, etc. and could invoke specific malicious stuff for those specific users includ
