I use aptitude as a Devuan user, but with vanilla aptitude it is not
possible to download changelogs for packages due to the hardcoded origin
check in generic/apt/pkg_changelog.cc:check_valid_origin:

https://sources.debian.org/src/aptitude/0.8.10-6/src/generic/apt/pkg_changelog.cc/#L691

Please can the whitelist be user-configurable?

For reference currently the recommended Devuan repo has no Origin
specified (it used to), but talking on IRC it sounds like they will fix
this if aptitude is changed to allow non-Debian repos as a valid source.

If being user-configurable is too much, presumably just more hardcoding
to allow 'Devuan' variants of what is already present?

Thanks

Hi,

OmegaPhil wrote:

We should at least make this more flexible. Not sure, what's the best
way.

There are though plans to further shrink the diff to Ubuntu by making
more stuff vendor-dependent.

And currently Ubuntu patches exactly these lines of code (plus more
related lines):
https://patches.ubuntu.com/a/aptitude/aptitude_0.8.10-6ubuntu1.patch

That's a really bad decision. Why have they done it? They don't gain
anything from it except breaking their infrastructure and annoying
their users.

Huh? That sounds a lot like extortion. If it was meant like that, they
won't get any farther — neither here nor anywhere else.

    Regards, Axel (running Debian Unstable with sysvinit or openrc)

[...]

For the record, I believe that this is a slight misunderstanding or
at the very least an exaggeration based solely on one hasty reply by
a single developer.

See above. Please, do not read too much into it!

Best regards
Irrwahn

Thanks for getting back so quickly - ah, that figures. I have an awful
hack locally
(https://git.devuan.org/devuan/devuan-project/uploads/15e61354c9588024eabc0a6fc4a3faaa/allow-devuan-repo-changelog-source-v2.patch
, now it has to fall back to the Label to check in the Devuan case).


Yes, they didn't think it was a notable issue. Devuan is also very busy
getting Ascii out the door, so its probably just down to being too busy.
Thank you for what you have said though - good evidence for me :)

I just wanted to clarify some of the things that were said above.

First of all, Devuan does not want to "extort" anything ;)

Second, OmegaPhil approached us on IRC saying that Devuan "had" to set
Origin, because having it blank was breaking "aptitude changelog",
which "verifies" the source of the repo. I pointed out that, according
to:

https://wiki.debian.org/DebianRepository/Format#Origin

Origin is an "Optional field indicating the origin of the repository,
a single line of free form text". So, the check currently implemented
in aptitude, based on matching the optional "single line of free form
text" contained in Origin, is *not* useful to "verify" anything. It
can only verify that the distributor (whoever they are, not
necessarily Debian or Ubuntu or Devuan) has put that specific string
in Origin.

We all know that the only way to check that a repo is genuinely from
Debian is by verifying that the corresponding Release files were
signed with the release keys published at:

https://ftp-master.debian.org/keys.html

so that specific check OmegaPhil is referring to is not adding any
extra level of security.

I personally think that a sane solution would be to have that check
configurable in aptitude, but I don't see it as a priority, TBH. My
personal take is that, if a fix is implemented, the users should be
warned that those extra checks based on Origin are only indicative,
and do not add any level of security.

Hope this helps to clarify this matter.

Thanks again for your work on Debian and aptitude: it is very much
appreciated.

HND

KatolaZ

Hi,

FWIW we added a `Changelogs` field to Debian's Release files so tools
like apt or aptitude no longer have to hardcode the source URL for
changelogs for every distribution.  This was requested by the apt
maintainers.

See https://lists.debian.org/debian-dak/2015/08/msg00012.html

Ansgar

Just as a followup on this (despite opening the bug I didn't receive
mail from it after the first response??) -
src/cmdline/cmdline_changelog.cc:do_cmdline_changelog has the following
comment:

========================================================================

      // For real packages/versions, we can do a sanity check on the
      // version and warn the user if it looks like it doesn't have a
      // corresponding source package.

========================================================================

It then proceeds to use aptitude::apt::check_valid_origin shortly after
- so it isn't a security check etc.

The other usage is in src/view_changelog.cc:view_changelog, where it is
probably used as a crutch to avoid validating the changelog data directly:

========================================================================

  // check if we know the origin
  if ( ! aptitude::apt::check_valid_origin(ver) )
    {
      check_apt_errors();
      return;
    }

...<proceeds to start processing the data>

========================================================================

libapt has the pkgAcqChangelog class which can be used for this, e.g.

new pkgAcqChangelog(&Fetcher, Ver, ".");

to download the changelog file to the current directory – without giving
a path it will us a temporary file. See apt-private/private-download.cc
and especially DoChangelog for the implementation of "apt(-get)
changelog" as a complete example.

Perhaps this is another command aptitude could delegate entirely by
calling apt – but I don't know aptitude specifics.


Best regards

David Kalnischkies

can something be done about this, please? this affects every 3rd party
repository, and it seems a bit off that aptitude can't do something that
the "regular" apt tools have done for years.

I’m wondering what the current status of this request is. It’s been open for quite a long time.
Having this feature would help immensly with our own private repositories, and being able to include a changelog in our packages.


Met vriendelijke groet,
Sebastiaan Brozius
+31636355624
sebastiaan.brozius@cloudnation.nl
www.cloudnation.nl