> We need "go-delete". Security is not important to us. There should be a 
balance between people that need security and people that don't need it.

Security might not be important to you, but it is important for the clients 
of your code—for the users that won't expect that a module provider removes 
their repo or specific versions of a module, thus breaking all downstream 
projects.

Remember left-pad 
<https://en.wikipedia.org/wiki/Npm_left-pad_incident#:~:text=As%20a%20result,their%20software%20products.>
.

A per-domain go-delete would not be any better than a global go-delete. An 
immutable log guarantees, or at least greatly increases, supply chain 
security. Allowing anyone to rug-pull their libraries (or even just 
rug-pull specific versions) effectively prohibits any supply chain 
security. 

Consider using the GOPROXY or GONOPROXY 
<https://go.dev/ref/mod#module-proxy:~:text=GOPROXY%20%E2%80%94%20list%20of,golang.org.>
 
environment variables during development to advise your Go toolchain to 
fetch specific or all modules directly rather than checking the proxy. Or 
use a Go workspace <https://go.dev/doc/tutorial/workspaces> that can 
redirect any dependency to a local directory. This way, a new module or a 
new module version won't hit the Go proxy as long as they're only 
downloaded directly, bypassing the proxy. You can then make all kinds of 
dumb mistakes (frankly, we all do!) during development and fix them without 
a trace. 

Once you push a release version, clients may download the module normally, 
that is, through the proxy, and thus engrave the released version into the 
log.


On Saturday, December 28, 2024 at 3:04:04 AM UTC+1 Jeffery Carr wrote:

> On Fri, Dec 27, 2024 at 7:30 PM Sean Liao <se...@liao.dev> wrote:
>
>> The zips (of your code) cached by the proxy can be removed.
>> The checksums held by the subdb cannot. The design for this is similar
>> to https://en.wikipedia.org/wiki/Certificate_Transparency not
>> blockchains which can hold arbitrary data.
>>
>
> It does hold arbitrary information.
>
> Allowing you to change the contents of a given module+version is a non
>> goal as that opens the ecosystem up to supply chain attacks.
>>
>
> Cool for those people that need that, but if this means I can't 
> "go-delete" and start over, kinda not helpful then.
>
> If the transparency log was domain based (make a log for each hostname in 
> the namespace) then this would be possible to more easily solve.
>
> peace,
> jcarr
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/3c660eb6-3e7b-4156-b235-b839daeb8a38n%40googlegroups.com.

Reply via email to