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

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

[James Hilliard]

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
- 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

The default value from the toolchain can be read with "go env GOPROXY"

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
 package/pkg-golang.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
index ffd50adecc..26da7be71b 100644
--- a/package/pkg-golang.mk
+++ b/package/pkg-golang.mk
@@ -101,7 +101,7 @@ $(2)_POST_PATCH_HOOKS += $(2)_GEN_GOMOD
 $(2)_DOWNLOAD_POST_PROCESS = go
 $(2)_DL_ENV += \
 	$$(HOST_GO_COMMON_ENV) \
-	GOPROXY=direct \
+	GOPROXY="https://proxy.golang.org,direct" \
 	$$($(2)_GO_ENV)
 
 # If building in a sub directory, do the vendoring in there
-- 
2.43.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 2/3] package/pkg-golang.mk: make GOPROXY configurable

[James Hilliard]

BR2_GOPROXY now configures the Go module proxy URL used to download Go modules
specified in project go.mod and go.sum files. By default, it uses Google's
official Go module mirror at proxy.golang.org, falling back to direct downloads
if the module is not found in the mirror.

The default value from the toolchain can be read with "go env GOPROXY"

We rely on package developers to audit their dependencies in go.mod and go.sum.

The value can be configured to:
- A comma-separated list of proxy URLs
- "off" to disable all downloads
- "direct" to download directly from source repositories

For more details on Go module proxies:
https://go.dev/ref/mod#module-proxy

Discussion:
https://lore.kernel.org/all/CADvTj4pXO2rwJ8oCzzGNY+OxLuo3uJnDT2PAxbyquw0L6dhfiA@mail.gmail.com/T/#t

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Christian Stewart <christian@aperture.us>
---
v1 -> v2:

 - added more context and links
 - renamed to GOPROXY instead of GOPROXY_LIST
 - moved into the !BR2_PRIMARY_SITE_ONLY section

v2 -> v3:
 - split out GOPROXY default change

Signed-off-by: Christian Stewart <christian@aperture.us>
---
 Config.in             | 16 ++++++++++++++++
 package/pkg-golang.mk |  2 +-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/Config.in b/Config.in
index d730f2034b..23717f3f97 100644
--- a/Config.in
+++ b/Config.in
@@ -335,6 +335,22 @@ config BR2_LUAROCKS_MIRROR
 
 	  See http://luarocks.org
 
+config BR2_GOPROXY
+	string "Go module proxy"
+	default "https://proxy.golang.org,direct"
+	depends on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS
+	help
+	  The Go module proxy URL used to download Go modules. By
+	  default, it uses the official Go module mirror, falling back
+	  to direct downloads if the module is not found in the mirror.
+
+	  The value can be one of:
+	    - Comma-separated list of proxy URLs
+	    - "off" to disable all downloads
+	    - "direct" to download directly from source repositories
+
+	  See https://go.dev/ref/mod#module-proxy
+
 config BR2_CPAN_MIRROR
 	string "CPAN mirror (Perl packages)"
 	default "https://cpan.metacpan.org"
diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
index 26da7be71b..3e388cb257 100644
--- a/package/pkg-golang.mk
+++ b/package/pkg-golang.mk
@@ -101,7 +101,7 @@ $(2)_POST_PATCH_HOOKS += $(2)_GEN_GOMOD
 $(2)_DOWNLOAD_POST_PROCESS = go
 $(2)_DL_ENV += \
 	$$(HOST_GO_COMMON_ENV) \
-	GOPROXY="https://proxy.golang.org,direct" \
+	GOPROXY=$$(call qstrip,$$(BR2_GOPROXY)) \
 	$$($(2)_GO_ENV)
 
 # If building in a sub directory, do the vendoring in there
-- 
2.43.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 3/3] package/tailscale: bump to version 1.88.3

[James Hilliard]

Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
---
 package/tailscale/tailscale.hash | 2 +-
 package/tailscale/tailscale.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/tailscale/tailscale.hash b/package/tailscale/tailscale.hash
index e2d600f03e..444412f8f4 100644
--- a/package/tailscale/tailscale.hash
+++ b/package/tailscale/tailscale.hash
@@ -1,3 +1,3 @@
 # Locally computed
-sha256  4830cd822a838d5d44fd5eeebd07a2aacaf0255fb3fb7d3852d57659f54e51bc  tailscale-1.78.1-go2.tar.gz
+sha256  98b51e95e84378ab280c5a8706508d493ab9152a0215f00f0f69e3ea2673ea0f  tailscale-1.88.3-go2.tar.gz
 sha256  d1ee1c7947d4b2c1963ea214d5324f1d4c89f2f1d0f0224889b4dfb868dad725  LICENSE
diff --git a/package/tailscale/tailscale.mk b/package/tailscale/tailscale.mk
index 3c6c7bce1e..141a5b98d6 100644
--- a/package/tailscale/tailscale.mk
+++ b/package/tailscale/tailscale.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-TAILSCALE_VERSION = 1.78.1
+TAILSCALE_VERSION = 1.88.3
 TAILSCALE_SITE = $(call github,tailscale,tailscale,v$(TAILSCALE_VERSION))
 TAILSCALE_LICENSE = BSD-3-Clause
 TAILSCALE_LICENSE_FILES = LICENSE
-- 
2.43.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[yann.morin]

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.

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.

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.

> - 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.

[--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?

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...

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

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.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [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@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.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Christian Stewart via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 1557 bytes --]

Hi James,

On Tue, Oct 21, 2025, 12:00 AM James Hilliard <james.hilliard1@gmail.com>
wrote:

> On Tue, Oct 21, 2025 at 12:30 AM <yann.morin@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.
>

Do we have a GitHub issue for the mismatched dependencies filed with
tailscale?

While I agree for performance it makes sense to use the proxy on default,
as this is no different than using say npm or pypi or any other package
store, nevertheless ...

It still makes me nervous to have these mismatches and treat them as a
matter of fact since it indicates something weird is going on, maybe
someone trying to hide malicious code in the proxy, so I think at least we
should test with direct as well and file GitHub issues for the mismatches.

In the past tailscale fixed several for us on request on GitHub issues.

Best regards,
Christian Stewart

[-- Attachment #1.2: Type: text/html, Size: 2252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[James Hilliard]

On Tue, Oct 21, 2025 at 10:52 AM Christian Stewart
<christian@aperture.us> wrote:
>
> Hi James,
>
> On Tue, Oct 21, 2025, 12:00 AM James Hilliard <james.hilliard1@gmail.com> wrote:
>>
>> On Tue, Oct 21, 2025 at 12:30 AM <yann.morin@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.
>
>
> Do we have a GitHub issue for the mismatched dependencies filed with tailscale?

I didn't really bother since this seems to be such a frequent issue.

> While I agree for performance it makes sense to use the proxy on default, as this is no different than using say npm or pypi or any other package store, nevertheless ...

One thing pypi does similar to goproxy is it essentially
guarantees hashes won't ever change.

> It still makes me nervous to have these mismatches and treat them as a matter of fact since it indicates something weird is going on, maybe someone trying to hide malicious code in the proxy, so I think at least we should test with direct as well and file GitHub issues for the mismatches.

Might be ok to mention to upstreams, but fixes generally don't seem
to come quickly either in general so I kind of stopped bothering.

> In the past tailscale fixed several for us on request on GitHub issues.
>
> Best regards,
> Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot