[pacman-dev] [PATCH] Convert download packages logic to multiplexed API

[Anatol Pomozov]

Hello

On Mon, Apr 20, 2020 at 4:53 AM Allan McRae <allan at archlinux.org> wrote:
>
> On 19/4/20 1:15 pm, Anatol Pomozov wrote:
> >> +                       /* TOASK: do we need to initiate *.sig file download here? */
>
> > One question with this change is whether we need to download the
> > package signatures here.
> >
> > It looks like the current codepath does not try to download *.sig
> > files. But at other place that fetches packages (alpm_fetch_pkgurl) we
> > actually *do* download sig files. So there is inconsistency between
> > different download codepaths.
> >
> > Also Arch does not use detached *.sig files for the packages. So I am
> > not sure what is the current plan regarding package signature files.
>
> Arch does have detached .sig files on its mirrors.
>
> The two download paths currently are:
>
> 1) -S <pkg>: this uses the signature from the db
> 2) -U <url>: this uses a signature if it finds one

-U codepath handles downloading package signatures already. Its logic
is essentially checking for this flag:
   handle->siglevel & ALPM_SIG_PACKAGE;

-S does not download the *.sig file.
My understanding that we need to download the signature if db SigLevel
is ether "Optional" or "Required".

> There is a bug report, which we have discussed implementing that asks us
> to always download signatures.  It would be good to add this while you
> are working on this area.

Sure I can look at it and send a separate patch for this new functionality.

What is the bug report number? I can't find the discussion at
bugs.archlinux.org.

>
> This has several advantages.  We can verify packages in our cache, even
> if they are no longer in the database.  And we could drop signatures
> from the databases, making them substantially smaller (we added them
> when the overhead was lower due to using less secure signing keys).

Sure I can implement it.