bug#74604: 30.0.92; FR: M-x package-upgrade - offer an option to show a diff on upgrade

[Ship Mints <shipmints@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

Isn't it the case that describe-package works only on installed packages,
not prospectively installed packages? To help determine the value/risk of a
package install or update, I'd think it better to show this in advance.
Daniel's diff suggestion is similar but more technical.

On Mon, Dec 2, 2024 at 3:59 AM Philip Kaludercic <philipk@posteo.net> wrote:

> Ship Mints <shipmints@gmail.com> writes:
>
> > I like this idea, too. I spend a reasonable amount of time trying to
> > understand what people have changed and if it will affect me negatively
> > (the defensive part) or positively (for new features, user options,
> > deprecations). Showing a source-code diff may be a bit technical for some
> > users, though. I wonder if there could be either a link to a changelog,
> or
> > a way to encourage a changelog convention so one could be displayed for
> > users prior to a decision to update a package.
>
> Note that packages can distribute this information.  Currently, if a
> tarball includes a "news" file, it will be displayed by
> `describe-package.  IIRC no package archive generates these right now.
> But if we implement a user option like that described above (or below?),
> then we can add that as an option as well.
>
> The main issue is that not all package maintainers ensure that there are
> changelog/news sources that ELPA could use to provide this information.
>
> > -Stephane
> >
> > On Sun, Dec 1, 2024 at 5:06 PM Philip Kaludercic <philipk@posteo.net>
> wrote:
> >
> >> Daniel Mendler <mail@daniel-mendler.de> writes:
> >>
> >> > This is a feature request for the security wishlist. When upgrading
> >> > package it would be good to show a diff between the new and old
> package
> >> > files. Such an option could help performing review casually as part of
> >> > the upgrade process and may improve the security of the package
> >> > archives. More eyes would look at new package versions. This would
> make
> >> > it harder to inject malicious code either via the source repository or
> >> > via attacks on the package archives.
> >>
> >> That sounds like a good option to have!  I'll look into adding something
> >> like this via a user option that adjusts how to confirm a package
> upgrade.
> >>
> >> Note that package-vc has something similar with the
> >> `package-vc-log-incoming' command.
> >>
> >>
> >>
> >>
>

[-- Attachment #2: Type: text/html, Size: 3201 bytes --]