[Buildroot] [PATCH v3 1/3] package/pkg-golang.mk: use golang toolchain default GOPROXY

[James Hilliard]

On Tue, Oct 21, 2025 at 12:30 AM <yann.morin at orange.com> wrote:
>
> James, All,
>
> Thanks for the quick respin (while the discussion was still on-going in
> a previous thread...)
>
> I was expecting that the order of patches would be the reverse:
>   - first, make it configurable, keeping the current default
>   - second change the default.
>
> If you first make it configurable and the patch is reverted, then the
> default patch would _technically_ have to be reverted too.

You'd also have to revert the tailscale package bump since that
package requires the caching proxy and will not build when using
GOPROXY=direct. So I wouldn't worry too much about that since
reverting would require package version bump reverts as well.

> With the ordering you propose, if the secod patch turns out to have an
> issue and is reverted, then the first patch would still be applied
> because it would not be _technically_ needed to revert it, and thus
> people would be forced to use a proxy.

I think the ordering I used is cleaner since we then shouldn't ever
set the kconfig value to direct(which is known to be broken for
packages like tailscale).

> On 2025-10-20 23:59 -0600, James Hilliard spake thusly:
> > This change sets the default GOPROXY value to match Go's built-in
> > default of "https://proxy.golang.org,direct" which provides several
> > benefits:
> >
> > - Avoid package breakages due to missing module sources
>
> As has been discussed in a previous thread, this is not always true, and
> has been proven to be false in certain circumstances.

I think you're referring to circumstances that likely don't really exist
in practice due to golang upstream packages always using the
caching proxy.

> > - Better alignment with upstream Go toolchain defaults
> > - Faster downloads via the proxy compared to direct Git clones
> > - Maintains reproducible builds through Go's module checksum validation
>
> We already have this feature in Buildroot, where all the sources
> archives are hash-checked already, so I'd argue that dependeing on the
> backend tooling (go in this case) is superfluous from the point of view
> of Buildroot.

I think you're missing the issue, a package like tailscale requires
the use of the caching proxy for dependencies to download, hence
buildroot doesn't really have any other option but to do the same.

If we did not do this then we wouldn't be able to deterministically
generate go package archives with vendored dependencies
properly from say a specific commit/tag for the go package as
upstreams basically always have checksums for the goproxy
based sources and not direct.

The buildroot hash checking happens after all this.

> [--SNIP--]
> > -     GOPROXY=direct \
> > +     GOPROXY="https://proxy.golang.org,direct" \
>
> So what happens if the archive cached in the goproxy does not match the
> one expected by the being-veondred package? Would go fallback to direct,
> or does it immediately abort the vendoring?

I think in general it will error if mismatched and fall back if missing,
but I wouldn't worry about that since basically all go packages use
the caching proxy so it should generally always work as expected.

The main reason for using the caching goproxy is so that we avoid
these mismatches entirely.

> If the go vendoring fallbacks to the next item in the list when it can't
> fownload from a previous one for whatever reason, such as missing in the
> proxy [0] or not matching hashes, then I would argue that "direct"
> should be the first in the list (to fetch from upstream preferentially,
> and only fallback to a goproxy only for those mnisbehaving packages...

>From my understanding this won't work since a mismatch will hard error,
we pretty much have to use the caching proxy since that's the go
toolchain default for generating the go checksums.

> [0] but then, if it is missing from the goproxy, why wouldn't it caches
> the archive it is missing?

It should cache generally, but fallback if the goproxy based download
fails entirely.

> Regards,
> Yann E. MORIN.
>
> --
>                                         ____________
> .-----------------.--------------------:       _    :------------------.
> |  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
> |                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
> | +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
> | yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
> '--------------------------------------:______/_____:------------------'
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.