My Emacs setup is on GitHub but I might have to finally get rid of my special package handling code and move to something else instead.
How about using straight together with use-package?
One of these days!
β#Emacs
(Please contact me if you want to remove your comment.)
β
Iβm having the same questions. The functional approach of straight is very appealing. Would this approach be able to increase the security ? With security, I mean the fact that the melpa is vulnerable to attacks, much more than a debian/any-other-distro repo or github for example.
β JeanMichel 2018-02-28 12:07 UTC
---
[of course you keep my email adress for you π ]
β JeanMichel 2018-02-28 12:08 UTC
---
To be honest, I have never thought much about the security of MELPA and friends. I suspect it is terrible, but then again, perhaps it is not if HTTPS is enabled and certificates are checked and all that, perhaps it is good enough? Debian doesnβt have HTTPS for its repos but has signature checking. We donβt have signatures but HTTPS? Fair? π€· I have no idea.
β Alex Schroeder 2018-02-28 13:54 UTC
---
Well, I started to worry about security in emacs after this discussion : https://www.reddit.com/r/emacs/comments/63e8hu/are_emacs_package_repositories_a_security_risk/?st=jejp9fmz&sh=a7ade519
Since then, there have been other discussions, which I have not followed accurately. Iβm not a specialist, but for those who use emace for everything like notes, mail etc, the possibility of an infected package should be a concern, and iβd love if there would be an approach to solve this.
But ... that is not your point in this post ! π
β JeanMichel 2018-03-09 08:55 UTC
---
https://glyph.twistedmatrix.com/2015/11/editor-malware.html
I found this a while ago, which says you have to do extra work to get Emacs to actually verify https.
β jpkotta 2018-03-09 17:03 UTC
---
Thank you both! Very interesting.
β Alex Schroeder 2018-03-11 21:17 UTC
---
straight.el uses hashes and a lockfile
https://github.com/raxod502/straight.elβ#lockfile-management
β straight user 2018-04-12 23:27 UTC